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.
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.
No it didn't. I posted that message too early...
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.
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.
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);
Thanks, Martin. I can confirm that this makes it work correctly.