Issue with CDI, Named beans and EAR packaging

[sverker <sv...@abrahamsson.com>]

I have an application deployed on Wildfly 8.2.0 with Wildfly-Camel 2.2.0 and
Camel 2.15.0 which is heavily using named beans in camel routes.

While upgrading the components to Wildfly 9.0.1 and Wildfly-Camel 3.1.0
which uses Camel 2.16.0 I hit the problem that Camel routes are unable to
find my named beans. I filed an issue on this to Wildfly-Camel github
project:

https://github.com/wildfly-extras/wildfly-camel/issues/978

Investigating a bit more I see that in Camel 2.15.0 Deltaspike will find the
beanmanager for my ejb jar, which knows about my named beans, but in 2.16.0
it uses an injected beanmanager which is for camel-cdi jar and which is
unable to find my beans.

However, it is only when the application is packaged as an ear that this
issue occurs. If the testcase is packaged as jar or war then the camel-cdi
BeanManager is able to find my named beans.

It is not clear to me which is the correct behaviour, if like in the older
implementation the BeanManager belonging to ejb jar must be found and
queried or if the query shoulde be delegated by appserver from camel-cdi
jar's BeanManager and it is that delegation that is failing.

This was changed in CdiBeanRegistry here:
https://github.com/apache/camel/commit/43c4b2c68aee4519bbc7070e9f3075bd687c92fb

Which is the correct behaviour?



--
View this message in context: http://camel.465427.n5.nabble.com/Issue-with-CDI-Named-beans-and-EAR-packaging-tp5773897.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Issue with CDI, Named beans and EAR packaging

[Antonin Stefanutti <an...@stefanutti.fr>]

Bean visibility in EAR is a difficult topic as this depends on EAR classloader hierarchy which is not standardised. This is well explained in https://struberg.wordpress.com/2015/02/18/cdi-in-ears/.

DeltaSpike BeanProvider API tries to work-around this by dealing with the classloaders used at boot time and runtime to retrieve the bean manager instance. The change introduced in Camel 2.15.0 goes into the right direction but may have been a bit too simplistic / aggressive in that regards.

To move forward on this, could you describe the minimal structure of your EAR that reproduces the issue. Then, a possibility might be an adaptation of that structure, a fix in the Camel CDI registry logic, a fix in Weld EE, or a discussion on CDI dev list.


> On 15 Nov 2015, at 13:17, sverker <sv...@abrahamsson.com> wrote:
> 
> I have an application deployed on Wildfly 8.2.0 with Wildfly-Camel 2.2.0 and
> Camel 2.15.0 which is heavily using named beans in camel routes.
> 
> While upgrading the components to Wildfly 9.0.1 and Wildfly-Camel 3.1.0
> which uses Camel 2.16.0 I hit the problem that Camel routes are unable to
> find my named beans. I filed an issue on this to Wildfly-Camel github
> project:
> 
> https://github.com/wildfly-extras/wildfly-camel/issues/978
> 
> Investigating a bit more I see that in Camel 2.15.0 Deltaspike will find the
> beanmanager for my ejb jar, which knows about my named beans, but in 2.16.0
> it uses an injected beanmanager which is for camel-cdi jar and which is
> unable to find my beans.
> 
> However, it is only when the application is packaged as an ear that this
> issue occurs. If the testcase is packaged as jar or war then the camel-cdi
> BeanManager is able to find my named beans.
> 
> It is not clear to me which is the correct behaviour, if like in the older
> implementation the BeanManager belonging to ejb jar must be found and
> queried or if the query shoulde be delegated by appserver from camel-cdi
> jar's BeanManager and it is that delegation that is failing.
> 
> This was changed in CdiBeanRegistry here:
> https://github.com/apache/camel/commit/43c4b2c68aee4519bbc7070e9f3075bd687c92fb
> 
> Which is the correct behaviour?
> 
> 
> 
> --
> View this message in context: http://camel.465427.n5.nabble.com/Issue-with-CDI-Named-beans-and-EAR-packaging-tp5773897.html
> Sent from the Camel - Users mailing list archive at Nabble.com.