Skip to end of metadata
Go to start of metadata

Overview

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.  

Local JNDI

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:

  • java:jboss/
  • java:/

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.

Binding entries to JNDI

There are several methods that can be used to bind entries into JNDI in AS7.

Using @EJB

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.

Using a deployment descriptor

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.

Programatically

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.

In the Naming Subsystem Configuration

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):

Remote JNDI

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.

remote:

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.

ejb:

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:

ejb:myapp/myejbjar/MyEjbName!com.test.MyRemoteInterface
ejb:myapp/myejbjar/MyStatefulName!comp.test.MyStatefulRemoteInterface?stateful

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.

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jun 11, 2012

    Don't know if this is just me - but printing the pages in these new AS7 documents - does NOT print the code examples, etc.   The outline box appears but the text inside, like code, is not there.

  2. Apr 10, 2013

    Jboss5.1 Migration to JBoss7.1 Custom-JNDI-Handling

    Hello together,

    in our applications we used to define jndi-mappings in jboss.xml:
    <?xml version="1.0" encoding="UTF-8"?>
    <jboss>
    <enterprise-beans>
    <session>
    <ejb-name>ContractPortfolioProcessServiceBean</ejb-name>
    <jndi-name>com/fja/ipl/customer/ilis/contractportfolio/ContractPortfolioProcessService</jndi-name>
    </session>
    </enterprise-beans>
    </jboss>

    ithis jboss.xml was placed then in META-INF of that ejb-jar

    So it was easy to lookup for that bean like:

    public static ContractPortfolioProcessService lookupContractPortfolioProcessService()
    throws NamingException {
    final Context context = new InitialContext();
    return (ContractPortfolioProcessService ) context.lookup("com/fja/ipl/customer/ilis/contractportfolio/ContractPortfolioProcessService");
    }
    jndi.properties{
    #JBoss
    java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
    java.naming.provider.url=jnp://localhost:1099
    java.naming.factory.url.pkgs=org.jboss.namingrg.jnp.interfaces
    }

    How can it be made on JBOSS7?

    Due ejb3-spec in JBOSS7 they can also define jboss-ejb3.xml like this:
    <jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
    xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:iiop="urn:iiop"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd
    http://java.sun.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-spec-2_0.xsd
    urn:iiop jboss-ejb-iiop_1_0.xsd"
    version="3.1"
    impl-version="2.0">
    <enterprise-beans>
    <session>
    <ejb-name>CounterBean</ejb-name>
    <mapped-name>org/jboss/as/quickstarts/ejb/remote/stateful/CounterBean</mapped-name>
    </session>
    </enterprise-beans>

    <assembly-descriptor>
    <iiop:iiop>
    <ejb-name>CounterBean</ejb-name>
    <iiop:binding-name>org/jboss/as/quickstarts/ejb/remote/stateful/CounterBean</iiop:binding-name>
    </iiop:iiop>
    </assembly-descriptor>
    </jboss:ejb-jar>

    It deploys also errorless. But i did not find any dokumentation to lookup my ejb like in example above.

    Who can help me giving a hint in this case?

    How is the jndi.properties-Configuration would be in this case?

    1. Apr 10, 2013

      Jboss7 IIOP-Client

         
      Hello together,

      investigating "getting started" for Jboss7 i have an example for an IIOP-Configuration: jboss-as-quickstart-master\jts\application-component-2(https://github.com/jboss-jdf/jboss-as-quickstart)

      there i found an jboss-ejb3.xml with configuration:
      <?xml version="1.0" encoding="UTF-8"?>
      <jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
      xmlns="http://java.sun.com/xml/ns/javaee"
      xmlns:iiop="urn:iiop"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd
      http://java.sun.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-spec-2_0.xsd
      urn:iiop jboss-ejb-iiop_1_0.xsd"
      version="3.1"
      impl-version="2.0">
      <assembly-descriptor>
      <iiop:iiop>
      <ejb-name>CounterBean</ejb-name>
      <iiop:binding-name>org/jboss/as/quickstarts/ejb/remote/stateful/CounterBean</iiop:binding-name>
      </iiop:iiop>
      </assembly-descriptor>
      </jboss:ejb-jar>

      And the Code calling this EJB from a Container would be like this:
      @EJB(lookup = "corbaname:iiop:localhost:3628#org/jboss/as/quickstarts/ejb/remote/stateful/CounterBean")
      RemoteCounter counterBean;

      My Question is, how would be the jndi.properies or else for the Client like this?

      public static RemoteCounter lookupRemoteStatefulCounter() throws NamingException
      Unknown macro: { \ final Hashtable jndiProperties = new Hashtable(); \ jndiProperties.put(Context.URL_PKG_PREFIXES,"org.jboss.ejb.client.naming"); \ \ //jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY,"org.jboss.naming.remote.client.InitialContextFactory"); \ // jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.cosnaming.CNCtxFactory"); \ //jndiProperties.put(Context.PROVIDER_URL,"corbaloc}



      My many attempts do not led to any success.

      I know there is another way to "lookup" an ejb on Jboss7 but i need it on this way. Please do not come with answer from the same sample-collection(f.e. ejb-remote).