CODEWITHSUNDEEP
javawildflycdiwildfly-swarm
forty-two
forty-two

Reputation: 12817

Wildfly and Wildfly-swarm injecting CDI beans from war deployment vs custom module

In the process of experimenting with Wildfly-swarm I have run into a strange situation regarding bean injection.

I have a very simple bean, more or less like this:

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

    public Foo getFoo() {
        return delegate;
    }
}

If I bundle this in a jar directly in the war deployment, everything works fine and as expected. However, I need internal parts of this implementation to be completely isolated from the application, why I packaged the service api and its implementation into separate jboss modules.

These modules are added to the swarm uberJar and my app depends on them through the MANIFEST Dependencies entry. Now, everything seems to work ok, the FooService bean is injected in my application servlet/rest resources, but the init() method is not called.

I cannot figure out what's going on here. It's like the bean resolution process doesn't recognize the @ApplicationScope annotation. Could there be two different class loaders for it?

UPDATE

I enabled tracing and to me it looks like Weld is treating the FooImpl class as ApplicationScoped, i.e. adding a LifecycleMixin.lifecycle_mixin_$$_postConstruct() to the proxy being created:

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]

The postconstruct interceptor isn't invoked--why? The mystery deepens!

UPDATE 2

Tested this on vanilla wildfly, and the behavior is the same, @PostConstruct method is not called if bean is located in module.

Upvotes: 0

Views: 596

Answers (1)

Siliarus
Siliarus

Reputation: 6753

I suppose this question and the one in JBoss forums are linked, but in case they aren't...

Probable cause is that your separate module does not declare dependency on <module name="javax.annotation.api"/> which is where @PostConstruct comes from. Adding it, should solve the trouble. This seems to be expected JVM behaviour (as explained in this SO question) - if you miss the dependency in runtime, the program will still execute but ignore the annotation.

As a way around this (if the above doesn't work or you can't do it) - you may make use of initializer methods. It is a method executed as soon as the object is created by CDI.

Upvotes: 0

Related Questions