Wildfly et Wildfly-swarm injectant des fèves CDI du déploiement de guerre vs module personnalisé

Question

En cours d'expérimentation avec Wildfly-swarm, j'ai été confronté à une situation étrange concernant l'injection de haricot.

J'ai un haricot très simple, plus ou moins comme ceci:

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

    public Foo getFoo() { 
     return delegate; 
    } 
} 

Si je Regroupez ce dans un bocal directement dans le déploiement de la guerre, tout fonctionne bien et comme prévu. Cependant, j'ai besoin que les parties internes de cette implémentation soient complètement isolées de l'application, pourquoi j'ai empaqueté l'API du service et son implémentation dans des modules jboss séparés.

Ces modules sont ajoutés à l'uberJar swarm et mon application dépend d'eux via l'entrée MANIFEST Dependencies. Maintenant, tout semble fonctionner correctement, le bean FooService est injecté dans mes ressources servlet/rest application, mais la méthode init() n'est pas appelée.

Je n'arrive pas à comprendre ce qui se passe ici. C'est comme si le processus de résolution du bean ne reconnaissait pas l'annotation @ApplicationScope. Pourrait-il y avoir deux chargeurs de classe différents pour cela?

MISE À JOUR

J'activé le suivi et pour moi, il ressemble à Weld traite la classe FooImpl comme ApplicationScoped, à savoir l'ajout d'un LifecycleMixin.lifecycle_mixin_$$_postConstruct() au proxy en cours de création:

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] 

L'ISN intercepteurs de PostConstruct pas invoqué - pourquoi? Le mystère s'approfondit!

UPDATE 2

testé ce wildfly sur la vanille, ainsi que le comportement est le même, la méthode de @PostConstruct est pas appelé si haricot est situé dans le module.

Answer 1

Je suppose que cette question et the one in JBoss forums sont liés, mais au cas où ils ne sont pas ...

Cause probable est que votre module séparé ne déclare pas dépendance à l'égard <module name="javax.annotation.api"/> qui est l'endroit où @PostConstruct vient. L'ajouter, devrait résoudre le problème. Cela semble être attendu comportement JVM (as explained in this SO question) - si vous manquez la dépendance dans l'exécution, le programme s'exécutera toujours mais ignorez l'annotation. Pour contourner ce problème (si ce qui précède ne fonctionne pas ou que vous ne pouvez pas le faire), vous pouvez utiliser les méthodes d'initialisation. C'est une méthode exécutée dès que l'objet est créé par CDI.