为什么即使 BeanManager 知道 EJB 也会出现 WELD-001408

【问题标题】：Why is there a WELD-001408 even when the BeanManager knows the EJB为什么即使 BeanManager 知道 EJB 也会出现 WELD-001408
【发布时间】：2016-03-08 00:43:05
【问题描述】：

在尝试部署耳朵时，我们得到了臭名昭著的 WELD-001408（请参阅下面的堆栈跟踪）。

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

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

更新 2： 我在github 上创建了一个最小的版本

首先是设置 - 最后是我的研究/发现和更详细的问题：

我们目前正在使用 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() I 看到，lib/shared.jar 的 BeanManager 有 AEjb 的实例 在他的 enterpriseBeans 集合中。在任何时候，此集合都不会用于查找依赖项。
  • 非 EJB 类（如 AnotherCdiDependency）的注入在 shared.jar 的类中可以正常工作
  • 通过 @Inject 将 AEjb 注入到位于 b-ejb.jar 中的 AnotherCdiManagedBeanPojo（读取：toplevel / /lib 之外）也可以正常工作

我的问题

  • 我的第一个问题：为什么 BeanManager 甚至不能注入 EJB 如果它知道吗？是否有任何标准说明共享库 不能注入“全局”EJB？如果有，在哪里可以找到？

  • “最简单”的方法是什么？简单意味着尽可能少地更改代码，并且不会造成我们以后遇到的麻烦。

  • 额外问题：这个评论是什么 BeanManagerImpl.getBeans(InjectionPoint injectionPoint) - 这个FAQ在哪里？

    我们总是缓存，我们假设人们不使用内联注释字面量声明，有点冒险但常见问题解答

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

免责声明：在我的研究过程中没有调用任何新的。

【问题讨论】：

  • 您是否尝试将 ejb-jar.xml 描述符添加到 ejb jar 中？
  • 我玩了一点...你能克隆github.com/StefanHeimberg/stackoverflow-34065368，在你的glassfish上构建和部署“parent/sample-app/target/sample-app-1.0-SNAPSHOT.ear”吗?然后看看输出。你能确认一切正常吗？ AStartupEJB -> BApplicationCDIBean -> BEJB
  • 你能看看另一个分支“call_bejb_over_shared_cdibean”吗？这是你的星座吗？我收到“WELD-001474：com.sample.shared.SharedApplicationCDIBean 类在类路径上，但由于找不到它引用的类而被忽略：com.sample .b.ejb.BEJB”。只是为了确保我可以重现你的情况......
  • 顺便说一句，，共享库的原因是什么？是ejbs使用的共享库吗？还是使用ejbs的共享库？如果是第二个，那我觉得这个“分层”不是最好的……/还是应该改……
  • 顺便说一句。你可以使用史蒂夫 C 的答案来让它工作......但我认为这不符合他所说的 java ee 规范。 （不便携）。我认为架构有问题。你有能力重构你的应用程序来解决这个问题吗？我认为这对您的应用程序的未来会更好。

标签： jakarta-ee ejb cdi glassfish-4 weld


【解决方案1】：

EAR 文件中的类可见性规则在 Java EE 规范 v7 的 §8 中进行了阐述。

总结：

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

出于类可见性的目的，EAR/lib 目录中的 jar 被认为位于单个模块中。 EAR/lib 模块类加载器中的类自动对所有其他模块可见（如第 8.3 节所述）。

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

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

一种可能的解决方案是将 shared.jar 移动到 EAR 的根目录中，并在每个 jar 中使用清单 Class-Path 条目以确保访问。

即。 shared.jar 中的 META-INF/MANIFEST.MF 将包含：

Class-Path: b-ejb.jar

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

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

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

【讨论】：

【解决方案2】：

您应该使用 @EJB 注释将 EJB 注入 CDI bean。

public class ACdiManagedBeanPojo {
  @EJB
  private AEjb aEjb;

  @Inject
  private AnotherCdiDependency anotherCdiDependency;        
}

为我在 GitHub 上的测试应用程序上工作并成功部署到 Payara 4.1.154

【讨论】：

    猜你喜欢
    • 2016-12-25
    • 2020-12-15
    • 1970-01-01
    • 1970-01-01
    • 2015-03-08
    • 2014-09-26
    • 1970-01-01
    • 1970-01-01
    • 2012-12-19
    相关资源
    最近更新 更多
    热门标签
    Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode