为什么即使 BeanManager 知道 EJB 也会出现 WELD-001408
Why is there a WELD-001408 even when the BeanManager knows the EJB
当尝试部署耳朵时，我们得到臭名昭著的 WELD-001408（堆栈跟踪见下文）。
问题：似乎 WELD 无法通过 @Inject 将 EJB 注入 lib/shared.jar.[=85= 中的 CDI 托管 bean (!= @ManagedBean) ]
为什么是这样？是否有标准表明这不应该起作用？
更新
我在相关位置也有一个 ejb-jar.xml...
更新2：
我在 github
上创建了一个最小版本
首先是设置 - 我的 research/findings 和最后更详细的问题：
我们目前使用的是 Glassfish 4.1 => Weld 2.2.2.Final，但是使用 Payara 4.1.1.154 => Weld 2.2.16.Final 时的错误是一样的，也是 Java EE 7
耳朵布局
sample.ear
├── a-ejb.jar (contains AEjb.java + beans.xml + ejb-jar.xml)
├── b-ejb.jar (contains AnotherCdiIManagedBeanPojo.java + DummyEjb.java + beans.xml)
├── lib
| └── shared.jar (contains ACdiManagedBeanPojo.java, AnotherCdiDependency.java + beans.xml)
└── META-INF
└── application.xml (...)
在shared.jar中有
public class ACdiManagedBeanPojo {
@Inject
private AEjb aEjb;
@Inject
private AnotherCdiDependency anotherCdiDependency;
}
AEjb 是驻留在 a-ejb.jar
中的 EJB
@javax.ejb.Singleton
@javax.ejb.LocalBean
@javax.enterprise.context.ApplicationScoped
public class AEjb {}
AnotherCdiDependency 是 shared.jar
中的另一个 Pojo
public class AnotherCdiDependency {}
以下class驻留在b-ejb.jar
public class AnotherCdiManagedBeanPojo {
@Inject
private AEjb aEjb;
}
beans.xml (CDI 1.1)
<beans bean-discovery-mode="all"
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd">
</beans>
ejb-jar.xml
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"
version="3.1">
<enterprise-beans>
<session>
<ejb-name>AEjb</ejb-name>
<ejb-class>com.xxx.ejb.AEjb</ejb-class>
<session-type>Singleton</session-type>
</session>
</enterprise-beans>
</ejb-jar>
堆栈跟踪
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type AEjb with qualifiers @Default
at injection point [BackedAnnotatedField] @Inject @Default private com.managed.pojo.ACdiManagedBeanPojo.aEjb
at com.managed.pojo.ACdiManagedBeanPojo.aEjb(ACdiManagedBeanPojo.java:0)
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:370)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:291)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:165)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:529)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:515)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:490)
at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:419)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:225)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:496)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access00(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:253)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:231)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:275)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.run(AbstractJavaResourceMethodDispatcher.java:151)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:171)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:387)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:331)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:103)
at org.glassfish.jersey.server.ServerRuntime.run(ServerRuntime.java:271)
at org.glassfish.jersey.internal.Errors.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:297)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:254)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:365)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:316)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access0(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
]]
研究与发现
- 调试中Validator.validateInjectionPointForDeploymentProblems()
看到，lib/shared.jar 的 BeanManager 有 AEjb 的实例
在他的 enterpriseBeans 集合中。此集合绝不会用于查找依赖项。
- none-EJB classes 的注入（如 AnotherCdiDependency）在 shared.jar
的 classes 中工作正常
- 通过@Inject 将 AEjb 注入驻留在 b-ejb.jar 中的 AnotherCdiManagedBeanPojo（阅读：toplevel / /lib 之外）也可以正常工作
我的问题
我的第一个问题：为什么BeanManager甚至不能注入EJB
如果它知道呢？是否有任何标准说共享库
不能用 "global" EJB 注入？如果是的话在哪里可以找到它？
解决这个问题的 "easiest" 方法是什么？简单意味着尽可能少地更改代码并且不会造成我们以后会遇到麻烦的大混乱。
奖金问题：这个评论是什么
BeanManagerImpl.getBeans(InjectionPoint injectionPoint) - 这个常见问题解答在哪里？
We always cache, we assume that people don't use inline annotation literal declarations, a little risky but FAQd
PS：我已经阅读了以下内容和许多其他有关 class 加载、上下文和 cdi 以及不同应用程序服务器与这些主题相关的特殊行为的内容 - 但仍然...
- https://struberg.wordpress.com/2015/02/18/cdi-in-ears/
- http://balusc.omnifaces.org/2013/10/cdi-behaved-unexpectedly-in-ear-so.html
免责声明：在我的研究过程中没有调用新的。
EAR 文件中 class 可见性的规则在 Java EE 规范 v7.
的第 8 节中列出
总结：
EAR 中的每个模块有效地获得了它自己的 class 加载器。
出于 class 可见性的目的，EAR/lib 目录中的 jars 被认为位于单个模块中。 Class EAR/lib 模块 class 加载器中的 Classes 自动对所有其他模块可见（如第 8.3 节所述）。
反之则不然。 ClassEAR/lib 模块中的模块无法自动访问其他模块中的内容。
一些 Java EE 实现提供了绕过这些限制的方法（以使您的应用程序不可移植为代价）。
一种可能的解决方案是将 shared.jar 移动到 EAR 的根目录中，并在每个 jar 中使用清单 Class-路径条目来确保访问。
即。 META-INF/MANIFEST.MF in shared.jar 将包含：
Class-Path: b-ejb.jar
如果您的 ejb-jars 需要在移动的 sample.jar 中看到 classes，那么他们将需要自己的清单 class-path 条目。
我认为需要移动 jar，因为根据我的经验，以下方法不起作用。
Class-Path: ../b-ejb.jar
您应该使用@EJB 批注将 EJB 注入到 CDI bean 中。
public class ACdiManagedBeanPojo {
@EJB
private AEjb aEjb;
@Inject
private AnotherCdiDependency anotherCdiDependency;
}
在 GitHub 上为我处理你的测试应用程序并成功部署到 Payara 4.1.154
当尝试部署耳朵时，我们得到臭名昭著的 WELD-001408（堆栈跟踪见下文）。
问题：似乎 WELD 无法通过 @Inject 将 EJB 注入 lib/shared.jar.[=85= 中的 CDI 托管 bean (!= @ManagedBean) ] 为什么是这样？是否有标准表明这不应该起作用？
更新 我在相关位置也有一个 ejb-jar.xml...
更新2： 我在 github
上创建了一个最小版本首先是设置 - 我的 research/findings 和最后更详细的问题：
我们目前使用的是 Glassfish 4.1 => Weld 2.2.2.Final，但是使用 Payara 4.1.1.154 => Weld 2.2.16.Final 时的错误是一样的，也是 Java EE 7
耳朵布局
sample.ear
├── a-ejb.jar (contains AEjb.java + beans.xml + ejb-jar.xml)
├── b-ejb.jar (contains AnotherCdiIManagedBeanPojo.java + DummyEjb.java + beans.xml)
├── lib
| └── shared.jar (contains ACdiManagedBeanPojo.java, AnotherCdiDependency.java + beans.xml)
└── META-INF
└── application.xml (...)
在shared.jar中有
public class ACdiManagedBeanPojo {
@Inject
private AEjb aEjb;
@Inject
private AnotherCdiDependency anotherCdiDependency;
}
AEjb 是驻留在 a-ejb.jar
中的 EJB@javax.ejb.Singleton
@javax.ejb.LocalBean
@javax.enterprise.context.ApplicationScoped
public class AEjb {}
AnotherCdiDependency 是 shared.jar
中的另一个 Pojopublic class AnotherCdiDependency {}
以下class驻留在b-ejb.jar
public class AnotherCdiManagedBeanPojo {
@Inject
private AEjb aEjb;
}
beans.xml (CDI 1.1)
<beans bean-discovery-mode="all"
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd">
</beans>
ejb-jar.xml
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"
version="3.1">
<enterprise-beans>
<session>
<ejb-name>AEjb</ejb-name>
<ejb-class>com.xxx.ejb.AEjb</ejb-class>
<session-type>Singleton</session-type>
</session>
</enterprise-beans>
</ejb-jar>
堆栈跟踪
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type AEjb with qualifiers @Default
at injection point [BackedAnnotatedField] @Inject @Default private com.managed.pojo.ACdiManagedBeanPojo.aEjb
at com.managed.pojo.ACdiManagedBeanPojo.aEjb(ACdiManagedBeanPojo.java:0)
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:370)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:291)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:165)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:529)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:515)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:490)
at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:419)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:225)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:496)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access00(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:253)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:231)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:275)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.run(AbstractJavaResourceMethodDispatcher.java:151)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:171)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:387)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:331)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:103)
at org.glassfish.jersey.server.ServerRuntime.run(ServerRuntime.java:271)
at org.glassfish.jersey.internal.Errors.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:297)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:254)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:365)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:316)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access0(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
]]
研究与发现
- 调试中Validator.validateInjectionPointForDeploymentProblems() 看到，lib/shared.jar 的 BeanManager 有 AEjb 的实例 在他的 enterpriseBeans 集合中。此集合绝不会用于查找依赖项。
- none-EJB classes 的注入（如 AnotherCdiDependency）在 shared.jar 的 classes 中工作正常
- 通过@Inject 将 AEjb 注入驻留在 b-ejb.jar 中的 AnotherCdiManagedBeanPojo（阅读：toplevel / /lib 之外）也可以正常工作
我的问题
我的第一个问题：为什么BeanManager甚至不能注入EJB 如果它知道呢？是否有任何标准说共享库 不能用 "global" EJB 注入？如果是的话在哪里可以找到它？
解决这个问题的 "easiest" 方法是什么？简单意味着尽可能少地更改代码并且不会造成我们以后会遇到麻烦的大混乱。
奖金问题：这个评论是什么 BeanManagerImpl.getBeans(InjectionPoint injectionPoint) - 这个常见问题解答在哪里？
We always cache, we assume that people don't use inline annotation literal declarations, a little risky but FAQd
PS：我已经阅读了以下内容和许多其他有关 class 加载、上下文和 cdi 以及不同应用程序服务器与这些主题相关的特殊行为的内容 - 但仍然...
- https://struberg.wordpress.com/2015/02/18/cdi-in-ears/
- http://balusc.omnifaces.org/2013/10/cdi-behaved-unexpectedly-in-ear-so.html
免责声明：在我的研究过程中没有调用新的。
EAR 文件中 class 可见性的规则在 Java EE 规范 v7.
的第 8 节中列出总结：
EAR 中的每个模块有效地获得了它自己的 class 加载器。
出于 class 可见性的目的，EAR/lib 目录中的 jars 被认为位于单个模块中。 Class EAR/lib 模块 class 加载器中的 Classes 自动对所有其他模块可见（如第 8.3 节所述）。
反之则不然。 ClassEAR/lib 模块中的模块无法自动访问其他模块中的内容。
一些 Java EE 实现提供了绕过这些限制的方法（以使您的应用程序不可移植为代价）。
一种可能的解决方案是将 shared.jar 移动到 EAR 的根目录中，并在每个 jar 中使用清单 Class-路径条目来确保访问。
即。 META-INF/MANIFEST.MF in shared.jar 将包含：
Class-Path: b-ejb.jar
如果您的 ejb-jars 需要在移动的 sample.jar 中看到 classes，那么他们将需要自己的清单 class-path 条目。
我认为需要移动 jar，因为根据我的经验，以下方法不起作用。
Class-Path: ../b-ejb.jar
您应该使用@EJB 批注将 EJB 注入到 CDI bean 中。
public class ACdiManagedBeanPojo {
@EJB
private AEjb aEjb;
@Inject
private AnotherCdiDependency anotherCdiDependency;
}
在 GitHub 上为我处理你的测试应用程序并成功部署到 Payara 4.1.154