Geek Answers Handbook

JBoss AS 7.1.1 JNDI bindings

When I deploy a typical EJB3 bean with the standard @Stateless, @Remote notes to my JBoss AS 7.1.1 , I see the following JNDI 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, then I find and call the bean from a stand-alone Java class (using code adapted from 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 listed name / binding spaces).

  • Why are there so many JNDI bindings provided and what's the difference if I use one or the other?
  • Is there a standard way, for example, possibly using the ejb: / namespace (since then, as shown in the quick start tutorial above).
  • Why is the ejb: / binding (which obviously has existed since I spoke with my bean) NOT reported in the output of JBoss AS 7.1.1?
+4
source share
2 answers

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

It was introduced in JBoss AS 7.x and replaces the standard remote JNDI method de facto using the same JNDI namespace as the local one, but provide the properties to the original context that indicates where the remote server is located.

The reason for the existence of ejb:/ twofold. According to JBoss, the de facto way to make JNDI remote access is not specified in the Java EE specification, so there is no reason to stick with it. One of the goals of JBoss AS 7 was to explore different ways of doing things, and because of its specification holes, remote EJBs were simply offered here.

With the ejb:/ namespace, it might be easier for the remote "driver" to intercept requests for the remote EJB beans and at the same time provide the ability to request only EJB beans and not tell the JMS queues (for which he also did not specify how to retrieve them remotely ) and worse than all data sources.

+4
source

1) They are all listed in the Java EE Specification (look at capter EE.5.2.2), but suffice it to say that they are “namespaces” and, depending on the “how” and “where” you are accessing these EJBs , you will get it based on each of these entries. For example, if code in the same module (EAR) requests an EJB, it will probably be routed through the java: module. The differences are mainly related to how optimized the call is, as accessing “comp” will require less “off-screen” work than “global”.

2) EE specification says:

This specification recommends, but does not require, links to enterprise beans to be organized in the sub-context ejb of application components (i.e., in the context of java: comp / env / ejb JNDI). Please note that bean enterprise links declared via annotations will by default not be any sub-context.

3) I do not have an answer to this, but maybe someone from #jboss (or # jboss-ejb3) on freenode might answer :-)

+4
source

More articles:


All Articles