12:51 p.m.
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>
To: "James Netherton" <jnethert(a)redhat.com>
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>
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>
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
--
Tomas Remes