Failure to get bean with BeanManager when using EAR archive

[gytis]

Hello,

we have been informed recently by one of our users on Narayana forum about an issue with our Compensations framework when the application using it is deployed as an EAR archive. When transactions is being completed/cancelled compensations framework instantiates completion/compensation handler implemented by the user by using BeanManager. For some reason this works fine if the handler is deployed in a JAR or a WAR. However, if the handler comes in a JAR which is in EAR, BeanManager doesn't find the bean. The error as this is thrown by compensations framework when CDI.current().getBeanManager().getBeans(clazz).iterator() returns an empty iterator: https://gist.github.com/gytis/a9773589e383d0f63ed8aa726dc7b93c.

I've put together a reproducer for this issue: quickstart/compensating-transactions/compensations-in-ear at bm-issue-with-ear · gytis/quickstart · GitHub. It has two tests in compensations-test module. One which invokes @Compensatable service (quickstart/HotelServiceImpl.java at bm-issue-with-ear · gytis/quickstart · GitHub) when it's deployed as a simple JAR (quickstart/HotelServiceEjbTest.java at bm-issue-with-ear · gytis/quickstart · GitHub). And another which invokes the same service when the same JAR is wrapped in EAR (quickstart/HotelServiceEarTest.java at bm-issue-with-ear · gytis/quickstart · GitHub).

Unsuccessful bean instantiation is initiated from the interceptor of @Compensatable with which the web service is annotated. You can see the stack trace in the error above, but it eventually ends up here: narayana/BeanManagerUtil.java at master · jbosstm/narayana · GitHub.

[manovotn]

I am trying to delve into this but so far I am failing to find the cause. Will keep trying anyway and if I find this above my skills, we can ask Martin for help on Monday.

Soo... let's take some wild guesses

So far I am thinking that the problem is that in EAR each module (war, ejb, ear/lib) is considered a separate module with separate class loading (so, yea... welcome to CL hell).

Whilst in plain war there is only one CL, which could be why it works in war.

The above would simply implicate that you cannot see the classes (from Narayana code you cannot see inside the EJB module), so we should seek a way to trick this. Try taking a look at Wildfly 10 class loading; I found some interesting info there, but so far didn't manage to pull off anything which would move me further. I tried things like deployment isolation, global modules etc. in order to extend EJB 'visibility'.

There might also be another way around - change the Narayana code to obtain "the right" bean manager from weld subsystem and query it for the bean instance. However, I haven't yet discovered how to do that (assuming it is possible).

I'll just keep digging, if you have any thoughts on this, I'll be happy to hear them.

[manovotn]

Did it work for you with <ear-subdeployments-isolated>false</ear-subdeployments-isolated>?

It sounds like a workaround but I am not sure there is any  clean solution to EARs :-/

What we are seeing might as well be "expected" behaviour due to class loading in EARs.

[gytis]

No it didn't. I posted that message too early...

[manuel_uberti]

Hi everybody. I am the one who reported the issue gytis is helping me to solve. Any update on this one?

[mkouba]

Hi guys,

the problem is the BeanManagerUtil from narayana/compensations receives the root BeanManager of the application archive. In a WAR, all the bean classes are accessible to the root BM (except for special cases - see also alternatives and specialization). However, in an EAR this BM does not see anything due to CL requirements of EE. I'm afraid there is no portable way how to fix this. The only way would be to get the right BM, i.e. make use of Weld API and/or Weld subsystem classes. We will look at this and keep you posted.

[mkouba]

gytis By the way, the way the BeanManagerUtil works is not entirely correct. First of all, it does not apply the ambiguous dependency resolution rules to a set of found beans (see also javax.enterprise.inject.spi.BeanManager.resolve(Set<Bean<? extends X>>)). Also this approach should not be used for @Dependent beans - see for example BeanProvider javadoc for explanation.

[mkouba]

So with the help of Weld core you should be able to find the BeanManager for a given class:

BeanManagerImpl beanManagerImpl = org.jboss.weld.bean.builtin.BeanManagerProxy.unwrap(CDI.current().getBeanManager());
BeanManager result = org.jboss.weld.manager.BeanManagerLookupService.lookupBeanManager(MyBean.class, beanManagerImpl);

[manuel_uberti]

Thanks Martin, I hope gytis and the rest of the Narayana team can do something about it.

[gytis]

Thanks, Martin. I can confirm that this makes it work correctly.