以前没这样用过,不过看上去,它像是 EJB3 引入了注解自动填充 EJB 引用后的一种 JBoss 特有的表示方式。这个应该是默认的我们部署描述符文件中没有指定 JNDI 绑定时的情况。
我觉得如果你是在 web 项目中引用同一个 EAR 项目内的某个 EJB 时应该不需要明确地写出这些东西,因为我们是通过 annotation 来做到的,既然 JBoss 自动把 EJB 部署到这些形式古怪的 JNDI 下,那么我们用 annotation 它也应该能通过类名就找到正确的 EJB,不需要我们配置 JNDI。
你启动时 JBoss 在控制台上显示了什么 binding JNDI 信息?这个是什么版本的 JBoss?
SecurityTraceability_EAR_1.0_Alpha 这个是 EAR 名字?
SecurityTraceability_Core_1.0_Alpha 这是一个 EJB session bean 名字还是 EJB jar 包名字?
我猜想的,menuEao!com.ampthon.st.eao.MenuEao 可能是对应着:
package com.ampthon.st.eao;
// 可能性 1.
@Stateless(name="menuEao")
public class MenuEaoImpl implements MenuEao {
// 可能性 2.
@EJB
private MenuEao menuEao;
}
至于是不是对,其实你启动 JBoss 时控制台会显示这些信息的,我之前和 JBoss 6 时就能看到部署一个 EAR/EJB 后这些 JNDI 绑定会列出来的,我们对照着看,就知道它把哪个 EJB 绑定到哪个 JNDI 下,然后添加的 EJB 引用又绑定到哪个 JNDI 下。
我觉得如果从容器外界远程访问,可能是使用 global 这种形式的,只不过,这种形式虽然是 JBoss 的表示方式,但一般我们可以明确地要求给出一个固定的 JNDI 而不是让 JBoss 自动生成一个自己想当然的又让人很难猜测的JNDI,比如在 @Stateless 中使用 mappedName (是这个用途么?以前我都是手写部署描述符,不知道 annotation 是怎么自动省掉的) 或者自己手写一份 jboss.xml 放到 META-INF 目录下,里面写上 ejb 部署描述符来配置JNDI和各种引用,这一样一来让程序尽可能地通用一点,把这些跟服务器环境相关的差异独立出来,让我们的代码不需要重新编译就可以通过修改配置描述符 xml 文件后部署到不同供应商的服务器上(xml 部署描述符虽然是代码的一部分,但很多服务器都在部署时提供一个部署向导到定制这些配置,因此代码不需要修改)。