JBoss AS offers several mechanisms to retrieve components by name. Every JBoss AS instance has it's own local JNDI namespace (java:) which is unique per JVM. The layout of this namespace is primarily governed by the Java EE specification. Applications which share the same JBoss AS instance can use this namespace to intercommunicate. In addition to local JNDI, a variety of mechanisms exist to access remote components.
- Client JNDI - This is a mechanism by which remote components can be accessed using the JNDI APIs, but without network round-trips. This approach is the most efficient, and removes a potential single point of failure. For this reason, it is highly recommended to use Client JNDI over traditional remote JNDI access. However, to make this possible, it does require that all names follow a strict layout, so user customizations are not possible. Currently only access to remote EJBs is supported via the ejb: namespace. Future revisions will likely add a JMS client JNDI namespace.
- Traditional Remote JNDI - This is a more familiar approach to EE application developers, where the client performs a remote component name lookup against a server, and a proxy/stub to the component is serialized as part of the name lookup and returned to the client. The client then invokes a method on the proxy which results in another remote network call to the underlying service. In a nutshell, traditional remote JNDI involves two calls to invoke an EE component, whereas Client JNDI requires one. It does however allow for customized names, and for a centralized directory for multiple application servers. This centralized directory is, however, a single point of failure.
- EE Application Client / Server-To-Server Delegation - This approach is where local names are bound as an alias to a remote name using one of the above mechanisms. This is useful in that it allows applications to only ever reference standard portable Java EE names in both code and deployment descriptors. It also allows for the application to be unaware of network topology details/ This can even work with Java SE clients by using the little known EE Application Client feature. This feature allows you to run an extremely minimal AS server around your application, so that you can take advantage of certain core services such as naming and injection.
The Java EE platform specification defines the following JNDI contexts:
- java:comp/ - The namespace is scoped to the current component (i.e. EJB)
- java:module/ - Scoped to the current module
- java:app/ - Scoped to the current application
- java:global/ - Scoped to the application server
In addition to the standard namespaces, AS7 also provides the following two global namespaces:
AS 7.1 also provides the java:jboss/exported/ context, entries bound to this context are accessible over remote JNDI.
|For web deployments java:comp/ is aliased to java:module/, so EJBs deployed in a WAR do not have their own component-scoped namespace.|
There are several methods that can be used to bind entries into JNDI in AS7.
Use the @EJB annotation to specify additional JNDI names for a bean. The bean below is bound to"java:global/MyBean" as well as the standard portable JNDI names.
For Java EE applications the recommended way is to use a deployment descriptor to create the binding. For example the following web.xml binds the string "Hello World" to java:global/mystring and the string "Hello Module" to java:comp/env/hello (which is aliased to java:module/env/hello, as this is a war deployment, so java:comp is the same as java:module).
For more details, see the Java EE Platform Specification or a Java EE tutorial.
Entries can also be bound to JNDI using Context.bind() in the normal fashion. The application server tracks which bindings belong to a deployment, and the bindings are automatically removed when the deployment is undeployed.
It is also possible to bind to one of the three global namespaces using configuration in the naming subsystem. This can be done by either editing the standalone.xml/domain.xml file directly, or through the management API.
Three different types of bindings are supported:
- Simple - A primitive or string.
- ObjectFactory - This allows to specify the javax.naming.spi.ObjectFactory that is used to create the looked up value.
- Lookup - This allows to create JNDI aliases. When this entry is looked up, it will lookup the target and return the result.
An example standalone.xml might look like:
To add these entries via the CLI:
To see all all options that are taken by the add command (this can actually be used to get the description of any CLI command):
AS 7.1 supports two different types of remote JNDI. The old jnp based JNDI implementation used in previous JBoss versions is no longer supported.
The remote: protocol uses the JBoss remoting protocol to lookup items from the servers local JNDI. To use it, you must have the appropriate jars on the class path, if you are maven user can be done simply by adding the following to your pom.xml:
If you are not using maven a shaded jar that contains all required classes
can be found in the bin/client directory of the AS 7.1 distribution.
The ejb: namespace is provided by the jboss-ejb-client library. This protocol allows you to look up EJB's, using their application name, module name, ejb name and interface type.
This is a client side JNDI implementation. Instead of looking up an EJB on the server the lookup name contains enough information for the client side library to generate a proxy with the EJB information. When you invoke a method on this proxy it will use the current EJB client context to perform the invocation. If the current context does not have a connection to a server with the specified EJB deployed then an error will occur. Using this protocol it is possible to look up EJB's that do not actually exist, and no error will be thrown until the proxy is actually used. The exception to this is stateful session beans, which need to connect to a server when they are created in order to create the session bean instance on the server.
Some examples are:
The first example is a lookup of a singleton, stateless or EJB 2.x home interface. This lookup will not hit the server, instead a proxy will be generated for the remote interface specified in the name. The second example is for a stateful session bean, in this case the JNDI lookup will hit the server, in order to tell the server to create the SFSB session.
For more details on how the server connections are configured, please see
EJB invocations from a remote client using JNDI.