Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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?
like image 507
Marcus Junius Brutus Avatar asked Feb 20 '23 14:02

Marcus Junius Brutus


1 Answers

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.

like image 97
Arjan Tijms Avatar answered Apr 27 '23 09:04

Arjan Tijms