即使BeanManager知道EJB,为什么还有WELD-001408

Question

当试图部署耳朵时,我们得到了臭名昭着的WELD-001408(见下面的stacktrace).

问题:似乎WELD无法通过@Inject将EJB注入到lib/shared.jar中的CDI托管bean(!= @ManagedBean)中. 为什么是这样？有没有一个标准说这不应该工作？

更新 我在相关位置也有一个ejb-jar.xml ...

UPDATE2: 我在github上创建了一个最小的versin

首先是设置 - 我的研究/调查结果以及最后的更详细的问题:

我们目前正在使用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 {}

以下类位于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$2$1.run(CommandRunnerImpl.java:539)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.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$2.execute(CommandRunnerImpl.java:534)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.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.access$1300(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$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
    at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.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$1.run(ServerRuntime.java:271)
    at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
    at org.glassfish.jersey.internal.Errors$1.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$2.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$9.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.access$100(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在他的enterpriseBeans集合中有AEjb的实例.在任何时候,此集合都不会用于查找依赖项.
• 注入非EJB类(如AnotherCdiDependency)在shared.jar的类中工作正常
• 通过@Inject将AEjb注入到驻留在b-ejb.jar中的AnotherCdiManagedBeanPojo(读取:toplevel// lib之外)也可以正常工作

我的问题

• 我的第一个问题:为什么BeanManager不能注入EJB,即使它知道它？有没有标准说共享库不能注入"全局"EJB？如果是这样在哪里找到它？

• 什么是"最简单"的出路？容易意味着改变尽可能少的代码并且不会造成大混乱,我们将在以后遇到麻烦.

• 额外问题:BeanManagerImpl.getBeans(InjectionPoint injectionPoint)中的这个注释是什么 - 这个FAQ在哪里？

  我们总是缓存,我们假设人们不使用内联注释文字声明,有点风险但FAQd

PS:我已经阅读了以下内容以及关于类加载,上下文和cdi以及不同应用程序服务器关于这些主题的特殊行为的许多其他内容 - 但仍然......

• https://struberg.wordpress.com/2015/02/18/cdi-in-ears/
• http://balusc.omnifaces.org/2013/10/cdi-behaved-unexpectedly-in-ear-so.html

免责声明:我的研究期间没有新的内容.

Answer 1

EAR 文件中类可见性的规则在 Java EE 规范 v7 的 \xc2\xa78 中列出。

\n\n

总之：

\n\n

EAR 中的每个模块都有效地获得它自己的类加载器。

\n\n

出于类可见性的目的，EAR/lib 目录中的 jar 被视为位于单个模块中。EAR/lib 模块类加载器中的类自动对所有其他模块可见（如 n \xc2\xa78.3 中所述）。

\n\n

反之则不然。EAR/lib 模块中的类不能自动访问其他模块中的类。

\n\n

一些 Java EE 实现提供了绕过这些限制的方法（代价是使应用程序不可移植）。

\n\n

一种可能的解决方案是将shared.jar 移至EAR 的根目录并使用每个jar 中的清单类路径条目来确保访问。

\n\n

IE。然后，shared.jar 中的 META-INF/MANIFEST.MF 将包含：

\n\n

Class-Path: b-ejb.jar\n

\n\n

如果您的 ejb-jar 需要查看移动的 example.jar 中的类，那么它们将需要自己的清单类路径条目。

\n\n

我认为需要移动罐子，因为根据我的经验，以下方法不起作用。

\n\n

Class-Path: ../b-ejb.jar\n

\n