4

当我使用标准@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 类（使用改编自JBoss AS 7.1.1 快速入门教程的代码）中找到并调用 bean：

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

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

  1. 为什么提供了这么多 JNDI 绑定，如果我使用其中的一个或另一个会有什么不同？
  2. 有没有标准的方法，例如可能使用ejb:/命名空间（因为这就是上面给出的快速入门教程中出现的内容）
  3. 为什么在 JBoss AS 7.1.1 输出中没有报告ejb:/绑定（显然存在，因为这是我用来与我的 bean 交谈的内容）？
4

2 回答 2

4

1) 这些都是在Java EE 规范中指定的（看看 capter EE.5.2.2），但足以说它们是“命名空间”，并且取决于“如何”和“从哪里”访问这些EJB，您最终会根据这些条目中的每一个来获得它。例如，如果同一模块 (EAR) 中的代码请求 EJB，它可能会通过 java:module 路由。区别主要在于调用的优化程度，因为“comp”访问需要的“幕后”工作比“全局”要少。

2）EE规范说：

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

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

于 2012-08-12T07:20:32.173 回答
4

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

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

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

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

于 2012-08-12T08:01:11.217 回答