CODEWITHSUNDEEP
ejb-3.0jndijboss7.x
Marcus Junius Brutus
Marcus Junius Brutus

Reputation: 27306

JBoss AS 7.1.1 JNDI bindings

When I deploy a typical EJB3 bean with the standard @Stateless, @Remote annotations to my JBoss AS 7.1.1 I see the following JNDI bindings on the server console output:

22:31:43,209 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor]    
(MSC service thread 1-2) JNDI bindings for session bean named HelloEJB3Bean
 in deployment unit deployment "hello.jar" are as follows:

    java:global/hello/HelloEJB3Bean!archetypesEjb3.IHelloEJB3
    java:app/hello/HelloEJB3Bean!archetypesEjb3.IHelloEJB3
    java:module/HelloEJB3Bean!archetypesEjb3.IHelloEJB3
    java:jboss/exported/hello/HelloEJB3Bean!archetypesEjb3.IHelloEJB3
    java:global/hello/HelloEJB3Bean
    java:app/hello/HelloEJB3Bean
    java:module/HelloEJB3Bean

However, I then find and call the bean from a standalone Java class (using code adapted from the JBoss AS 7.1.1 quickstart tutorials) using a JNDI String of the following type:

String jndiName = "ejb:" + appName + "/"      + moduleName + "/" + distinctName
                         + "/"     + beanName + "!" + viewClassName
                         + (stateful?"?stateful":"");

(which does not fall into one of the above namespaces / bindings).

  1. Why are so many JNDI bindings provided and what difference does it make if I use one or the other?
  2. Is there a standard way to go, e.g. maybe using the ejb:/ namespace (since that's what appears in the quickstart tutorial given above)
  3. Why is the ejb:/ binding (which obviously exists since that's what I used to talk to my bean) NOT reported in JBoss AS 7.1.1 output?

Upvotes: 4

Views: 6413

Answers (2)

Arjan Tijms
Arjan Tijms

Reputation: 38163

ejb:/ is the proprietary namespace used by JBoss for remote clients.

It was introduced in JBoss AS 7.x and replaces the de facto standard remote JNDI way of using the same JNDI namespace as you would do locally, but provide the properties to the initial context that specify where the remote server is located.

The reason for ejb:/ to exist is twofold. According to JBoss, the de facto way to do remote JNDI access is not specified in the Java EE spec, so there's no reason to adhere to it. One of the goals for JBoss AS 7 was to investigate different ways of doing things, and because of its specification holes, remote EJBs simply offered on opportunity here.

With the ejb:/ namespace, its supposedly easier for the remote 'driver' to intercept requests for remote EJB beans and at the same time makes sure only EJB beans can be requested, and not say JMS queues (for which it's also not specified how to obtain them remotely) and worst of all datasources.

Upvotes: 4

jpkroehling
jpkroehling

Reputation: 14061

1) Those are all specified in the Java EE specification (take a look at the capter EE.5.2.2), but suffice to say that they are "namespaces" and, depending on "how" and "where from" you access these EJBs, you'll end up getting it based on each of these entries. For instance, if a code in the same module (EAR) requests an EJB, it probably will be routed through the java:module. The differences are mainly in how optimized the call will be, as a "comp" access will require less "behind-the-scenes" work than a "global".

2) The EE specification says:

This specification recommends, but does not require, that references to enterprise beans be organized in the ejb subcontext of the application component’s environment (that is, in the java:comp/env/ejb JNDI context). Note that enterprise bean references declared via annotations will not, by default, be in any subcontext.

3) I don't have an answer for that, but perhaps someone at #jboss (or #jboss-ejb3) on freenode can answer :-)

Upvotes: 4

Related Questions