Question

当我使用标准 @Stateless ， @Remote 注释将典型的 EJB3 bean部署到我的 JBoss AS 7.1.1时我在服务器控制台输出上看到以下 JNDI 绑定：

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

但是，然后我使用以下类型的 JNDI 字符串从一个独立的Java类（使用从the JBoss AS 7.1.1 quickstart tutorials改编的代码）中查找并调用该bean：

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

（不属于上述命名空间/绑定之一）。

为什么提供了这么多JNDI绑定，如果我使用其中一个，会有什么不同？
是否有标准的方法，例如也许使用 ejb：/ 命名空间（因为这是上面给出的快速入门教程中出现的内容）
为什么 ejb：/ 绑定（显然存在，因为我以前与我的bean交谈）在JBoss AS 7.1.1输出中没有报告？

Answer 1

1）这些都在Java EE specification中指定（看一下封面EE.5.2.2），但足以说它们是“名称空间”，并且取决于“如何”和“哪里”从“您访问这些EJB，您最终将基于这些条目获取它。例如，如果同一模块（EAR）中的代码请求EJB，则它可能将通过java：模块进行路由。差异主要在于如何优化呼叫，因为“comp”访问需要的“幕后”工作比“全局”要少。

2）EE规范说：

本规范建议但不要求在应用程序组件的ejb子上下文中组织对企业bean的引用。环境（即java：comp / env / ejb JNDI上下文中）。请注意，默认情况下，通过注释声明的企业bean引用不会包含在内任何子上下文。

3）我没有答案，但也许freenode上的#jboss（或＃jboss-ejb3）的某个人可以回答:-)

Answer 2

ejb:/是JBoss用于远程客户端的专有命名空间。

它是在JBoss AS 7.x中引入的，它取代了事实上的标准远程JNDI方式，使用与本地相同的JNDI命名空间，但为初始上下文提供了指定远程服务器所在位置的属性。

ejb:/存在的原因是双重的。根据JBoss的说法，Java EE规范中没有指定实现远程JNDI访问的事实上的方法，因此没有理由遵守它。 JBoss AS 7的目标之一是研究不同的处理方式，并且由于其规范漏洞，远程EJB只是在这里提供了机会。

使用ejb:/命名空间，远程“驱动程序”更容易拦截远程EJB bean的请求，同时确保只能请求EJB bean，而不是说JMS队列（对于它也没有指定如何远程获取它们以及最差的数据源。

JBoss AS 7.1.1 JNDI绑定

2 个答案: