[wildfly-dev] BeanManager usage in EAR deployments
James Netherton
jnethert at redhat.com
Mon Dec 7 07:43:12 EST 2015
Hi Martin,
Thanks for pointing that out.
Does anyone know why this logic only applies to specific bean archive types (E.g EXTERNAL and SYNTHETIC but not EXPLICIT)?
I ended up getting things working by writing my own DeploymentUnitProcessor to mimic some the logic in WeldDeployment.makeTopLevelBdasVisibleFromStaticModules. Not sure if this is the correct thing to do though and whether the real 'fix' should be on the WildFly side.
Cheers,
James
----- Original Message -----
From: "Martin Kouba" <mkouba at redhat.com>
To: "James Netherton" <jnethert at redhat.com>, "Tomas Remes" <tremes at redhat.com>
Cc: wildfly-dev at lists.jboss.org
Sent: Friday, 4 December, 2015 1:19:09 PM
Subject: Re: [wildfly-dev] BeanManager usage in EAR deployments
Hi James,
so I went through the Weld integration code again and found out that
static modules (external bean archives) can only see bean archives from
top-level deployment units [1]. For WAR this works as you expect.
However, for EAR this set only contains bean archives from EAR/lib (i.e.
not EJB jars or WARs). I'm not really sure what should be done here though.
Martin
[1]
https://github.com/wildfly/wildfly/blob/master/weld/src/main/java/org/jboss/as/weld/deployment/WeldDeployment.java#L136
Dne 4.12.2015 v 12:51 James Netherton napsal(a):
> 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 at redhat.com>
> To: "James Netherton" <jnethert at redhat.com>
> Cc: wildfly-dev at 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 at redhat.com>
> To: wildfly-dev at 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/scenario-3/src/test/java/com/jamesnetherton/tests/cdi/war/CdiWarWithModularizedDependenciesTest.java
>
> https://github.com/jamesnetherton/camel-cdi-ear-tests/blob/master/scenario-4/src/test/java/com/jamesnetherton/tests/cdi/jar/CdiJarWithModularizedDependenciesTest.java
>
> 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 at aon.at>
> To: wildfly-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
More information about the wildfly-dev
mailing list