Hi all, I'm using Apache Camel with its CDI component (which uses DeltaSpike). Can anyone help to clarify the behavior I see with the CDI BeanManager in the following deployment scenarios. If I deploy my Camel application as an EAR deployment with the camel dependencies contained in the EAR archive lib directory: - my-application.ear |--- lib |--- camel-cdi-2.16.1.jar |--- camel-core-2.16.1.jar |--- deltaspike-core-api-1.5.1.jar |--- deltaspike-core-impl-1.5.1.jar |--- my-module.jar |--- META-INF |--- beans.xml |--- com.myapplication |--- Bootstrap.class |--- HelloBean.class Camel is capable of resolving beans that I have annotated with @Named through this BeanManager used by the Camel CDI extension: Weld BeanManager for my-camel-cdi-app.ear.external.jar:file:/home/james/.m2/repository/org/apache/camel/camel-cdi/2.16.1/camel-cdi-2.16.1.jar!/META-INF/beans.xml [bean count=42] However, if I deploy an EAR with a JAR sub-deployment and modularize my Camel dependencies like this: - my-application.ear |--- my-module.jar |--- META-INF |--- beans.xml |--- com.myapplication |--- Bootstrap.class |--- HelloBean.class - module: org.apache.camel.cdi:main |-- camel-cdi-2.16.1.jar |-- camel-core-2.16.1.jar |-- deltaspike-core-api-1.5.1.jar |-- deltaspike-core-impl-1.5.1.jar The BeanManager assigned to the Camel CDI extension is no longer capable of resolving my @Named annotated beans (HelloBean.class). Is this the expected behavior in this deployment scenario? There's some test cases which may explain things better here: https://github.com/jamesnetherton/camel-cdi-ear-tests Any help to clarify would be appreciated. Cheers, James _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Hi all, I'm using Apache Camel with its CDI component (which uses DeltaSpike). Can anyone help to clarify the behavior I see with the CDI BeanManager in the following deployment scenarios. If I deploy my Camel application as an EAR deployment with the camel dependencies contained in the EAR archive lib directory: - my-application.ear    |--- lib         |--- camel-cdi-2.16.1.jar         |--- camel-core-2.16.1.jar         |--- deltaspike-core-api-1.5.1.jar         |--- deltaspike-core-impl-1.5.1.jar    |--- my-module.jar         |--- META-INF              |--- beans.xml         |--- com.myapplication              |--- Bootstrap.class              |--- HelloBean.class   Camel is capable of resolving beans that I have annotated with @Named through this BeanManager used by the Camel CDI extension: Weld BeanManager for my-camel-cdi-app.ear.external.jar:file:/home/james/.m2/repository/org/apache/camel/camel-cdi/2.16.1/camel-cdi-2.16.1.jar!/META-INF/beans.xml [bean count=42] However, if I deploy an EAR with a JAR sub-deployment and modularize my Camel dependencies like this: - my-application.ear    |--- my-module.jar         |--- META-INF              |--- beans.xml         |--- com.myapplication              |--- Bootstrap.class              |--- HelloBean.class               - module: org.apache.camel.cdi:main |-- camel-cdi-2.16.1.jar |-- camel-core-2.16.1.jar |-- deltaspike-core-api-1.5.1.jar |-- deltaspike-core-impl-1.5.1.jar The BeanManager assigned to the Camel CDI extension is no longer capable of resolving my @Named annotated beans (HelloBean.class). Is this the expected behavior in this deployment scenario? There's some test cases which may explain things better here: https://github.com/jamesnetherton/camel-cdi-ear-tests Any help to clarify would be appreciated. Cheers, James _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Hi Tom, I just tried that, but the test result is the same unfortunately (with the camel module dependency present in the EAR manifest). James James Netherton Senior Engineer JBoss Fuse IRC: jnetherton | Twitter: @nethertron2000 | GitHub: jamesnetherton ----- Original Message ----- From: "Tomas Remes" <tremes(a)redhat.com&gt; To: "James Netherton" <jnethert(a)redhat.com&gt; Cc: wildfly-dev(a)lists.jboss.org Sent: Friday, 4 December, 2015 10:46:46 AM Subject: Re: [wildfly-dev] BeanManager usage in EAR deployments Hi, Did you try to add manifest dependency for "org.apache.camel.cdi" directly to EAR/META-INF/manifest? I guess it could work. I would try your test but there it is overwritten by using Arquillian JMX protocol so not easily adjustable. Tom ----- Original Message ----- From: "James Netherton" <jnethert(a)redhat.com&gt; To: wildfly-dev(a)lists.jboss.org Sent: Friday, December 4, 2015 10:09:50 AM Subject: Re: [wildfly-dev] BeanManager usage in EAR deployments Thanks for the responses so far. The modularized approach works fine for standard JAR or WAR deployments. The BeanManager from the org.apache.camel.cdi module seems to be able to resolve the application beans. As demonstrated here: https://github.com/jamesnetherton/camel-cdi-ear-tests/blob/master/scenari... https://github.com/jamesnetherton/camel-cdi-ear-tests/blob/master/scenari... There only seems to be an issue with EAR / JAR sub-deployments. Which leaves me wondering what's different in this scenario that stops things working. ----- Original Message ----- From: "Thomas Frühbeck" <fruehbeck(a)aon.at&gt; To: wildfly-dev(a)lists.jboss.org Sent: Thursday, 3 December, 2015 9:36:04 PM Subject: Re: [wildfly-dev] BeanManager usage in EAR deployments it seems that you are trying to resolve a dependency from inside module org.apache.camel.cdi, w/o having declared the dependency in your module.xml I don't know if it is _possible_ to define a dependency in a module which relates to an EAR resource, means reverse to the dependency graph. anyway I would not expect it to work thomas Am 03.12.2015 um 11:34 schrieb James Netherton: > Hi all, > > I'm using Apache Camel with its CDI component (which uses DeltaSpike). Can anyone help to clarify the behavior I see with the CDI BeanManager in the following deployment scenarios. > > If I deploy my Camel application as an EAR deployment with the camel dependencies contained in the EAR archive lib directory: > > - my-application.ear > |--- lib > |--- camel-cdi-2.16.1.jar > |--- camel-core-2.16.1.jar > |--- deltaspike-core-api-1.5.1.jar > |--- deltaspike-core-impl-1.5.1.jar > |--- my-module.jar > |--- META-INF > |--- beans.xml > |--- com.myapplication > |--- Bootstrap.class > |--- HelloBean.class > > Camel is capable of resolving beans that I have annotated with @Named through this BeanManager used by the Camel CDI extension: > > Weld BeanManager for my-camel-cdi-app.ear.external.jar:file:/home/james/.m2/repository/org/apache/camel/camel-cdi/2.16.1/camel-cdi-2.16.1.jar!/META-INF/beans.xml [bean count=42] > > However, if I deploy an EAR with a JAR sub-deployment and modularize my Camel dependencies like this: > > - my-application.ear > |--- my-module.jar > |--- META-INF > |--- beans.xml > |--- com.myapplication > |--- Bootstrap.class > |--- HelloBean.class > > > - module: org.apache.camel.cdi:main > |-- camel-cdi-2.16.1.jar > |-- camel-core-2.16.1.jar > |-- deltaspike-core-api-1.5.1.jar > |-- deltaspike-core-impl-1.5.1.jar > > The BeanManager assigned to the Camel CDI extension is no longer capable of resolving my @Named annotated beans (HelloBean.class). Is this the expected behavior in this deployment scenario? There's some test cases which may explain things better here: > > https://github.com/jamesnetherton/camel-cdi-ear-tests > > Any help to clarify would be appreciated. > > Cheers, > > James > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev