【问题标题】:Wildfly and Wildfly-swarm injecting CDI beans from war deployment vs custom moduleWildfly 和 Wildfly-swarm 从战争部署与自定义模块注入 CDI bean
【发布时间】:2018-02-23 18:39:33
【问题描述】:

在试验 Wildfly-swarm 的过程中,我遇到了一个关于 bean injection 的奇怪情况。

我有一个非常简单的 bean,或多或少是这样的:

@ApplicationScoped
public class FooServiceImpl implements FooService {
    Foo delegate;
    @PostConstruct public void init() {
        delegate = .....;
    }

    public Foo getFoo() {
        return delegate;
    }
}

如果我直接在战争部署中将其捆绑在一个 jar 中,则一切正常且符合预期。但是,我需要将此实现的内部部分与应用程序完全隔离,为什么我将服务 api 及其实现打包到单独的 jboss 模块中。

这些模块被添加到 swarm uberJar 中,我的应用程序通过 MANIFEST Dependencies 条目依赖它们。现在,一切似乎都正常,FooService bean 被注入到我的应用程序 servlet/rest 资源中,但没有调用 init() 方法。

我无法弄清楚这里发生了什么。就像 bean 解析过程无法识别 @ApplicationScope 注释一样。它可以有两个不同的类加载器吗?

更新

我启用了跟踪,在我看来 Weld 将 FooImpl 类视为 ApplicationScoped,即向正在创建的代理添加 LifecycleMixin.lifecycle_mixin_$$_postConstruct()

2017-09-14 23:11:34,315 TRACE [org.jboss.weld.Bean] (ServerService Thread Pool -- 12) WELD-001538: Created context instance for bean Managed Bean [class com.xxx.FooImpl] with qualifiers [@Any @Default] identified as WELD%ManagedBean%test.war|test.war.external.file:/tmp/nestedjarloader2449602760983533131.tmp/META-INF/beans.xml|com.xxx.FooImpl|null|false
2017-09-14 23:11:34,315 TRACE [org.jboss.weld.Bean] (ServerService Thread Pool -- 12) WELD-001542: Retrieving/generating proxy class com.xxx.FooImpl$Proxy$_$$_WeldClientProxy
2017-09-14 23:11:34,315 TRACE [org.jboss.weld.Bean] (ServerService Thread Pool -- 12) WELD-001541: Adding method to proxy: public void com.xxx.FooImpl.registerMessageHandler(com.xxx.MessageHandler)
2017-09-14 23:11:34,315 TRACE [org.jboss.weld.Bean] (ServerService Thread Pool -- 12) WELD-001541: Adding method to proxy: public void com.xxx.FooImpl.registerListeners(java.util.EventListener[])
2017-09-14 23:11:34,316 TRACE [org.jboss.weld.Bean] (ServerService Thread Pool -- 12) WELD-001541: Adding method to proxy: public void com.xxx.FooImpl.send(com.xxx.MessageHandler,com.xxx.Message) throws java.io.IOException
2017-09-14 23:11:34,316 TRACE [org.jboss.weld.Bean] (ServerService Thread Pool -- 12) WELD-001541: Adding method to proxy: public void com.xxx.FooImpl.init()
2017-09-14 23:11:34,316 TRACE [org.jboss.weld.Bean] (ServerService Thread Pool -- 12) WELD-001541: Adding method to proxy: public java.lang.String java.lang.Object.toString()
2017-09-14 23:11:34,316 TRACE [org.jboss.weld.Bean] (ServerService Thread Pool -- 12) WELD-001541: Adding method to proxy: public abstract void org.jboss.weld.interceptor.proxy.LifecycleMixin.lifecycle_mixin_$$_postConstruct()
2017-09-14 23:11:34,316 TRACE [org.jboss.weld.Bean] (ServerService Thread Pool -- 12) WELD-001541: Adding method to proxy: public abstract void org.jboss.weld.interceptor.proxy.LifecycleMixin.lifecycle_mixin_$$_preDestroy()
2017-09-14 23:11:34,317 TRACE [org.jboss.weld.Bean] (ServerService Thread Pool -- 12) WELD-001543: Created Proxy class of type class com.xxx.FooImpl$Proxy$_$$_WeldClientProxy supporting interfaces [interface com.xxx.FooService, interface java.io.Serializable, interface org.jboss.weld.interceptor.proxy.LifecycleMixin, interface org.jboss.weld.interceptor.util.proxy.TargetInstanceProxy, interface org.jboss.weld.bean.proxy.ProxyObject]
2017-09-14 23:11:34,317 TRACE [org.jboss.weld.Bean] (ServerService Thread Pool -- 12) WELD-001506: Created new client proxy of type class com.xxx.FooImpl$Proxy$_$$_WeldClientProxy for bean Managed Bean [class com.xxx.FooImpl] with qualifiers [@Any @Default] with ID WELD%ManagedBean%test.war|test.war.external.file:/tmp/nestedjarloader2449602760983533131.tmp/META-INF/beans.xml|com.xxx.FooImpl|null|false
2017-09-14 23:11:34,318 TRACE [org.jboss.weld.Bean] (ServerService Thread Pool -- 12) WELD-001507: Located client proxy of type class com.xxx.FooImpl$Proxy$_$$_WeldClientProxy for bean Managed Bean [class com.xxx.FooImpl] with qualifiers [@Any @Default]

postconstruct 拦截器没有被调用——为什么?谜团加深!

更新 2

在 vanilla wildfly 上测试过,行为相同,如果 bean 位于模块中,则不会调用 @PostConstruct 方法。

【问题讨论】:

  • 如果您将 API 和 Impl 放在单独的 JBoss 模块中,那么它们确实位于单独的类加载器中。 MANIFEST 中 impl 的 module.xml 是否确定它应该被“导入”到 WAR 类加载器中?
  • @Ken 不,它没有,但应该吗?我的意思是,我希望 impl 在它自己的类加载器中,ApplicationScoped 应该只来自一个类加载器。

标签: java wildfly cdi wildfly-swarm


【解决方案1】:

我想这个问题和the one in JBoss forums 是有关联的,但万一他们不是……

可能的原因是 您的单独模块未声明对 <module name="javax.annotation.api"/> 的依赖关系,而 @PostConstruct 来自该模块。添加它,应该可以解决问题。 这似乎是预期的 JVM 行为 (as explained in this SO question) - 如果您在运行时错过了依赖项,程序仍将执行但忽略注释。

作为一种解决方法(如果上述方法不起作用或您不能这样做)- 您可以使用初始化方法。它是 CDI 创建对象后立即执行的方法。

【讨论】:

  • 他们确实有联系:)
猜你喜欢
  • 2017-04-13
  • 2014-03-18
  • 2018-04-12
  • 2014-03-29
  • 2014-02-26
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-07-09
相关资源
最近更新 更多