[wildfly-dev] BeanManager usage in EAR deployments

[Tomas Remes]

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

-- 
Tomas Remes