Hello Xavier Mourgues, let me start by pointing out that you are jumping from Weld 1.x to 3.x which means you are going from CDI 1.0 to 2.0. That's quite a huge leap and not everything will work the same. Now as for the issue itself - we are talking modular deployments which have some restrictions on visibility (in accordance to what umbrella EE spec requires) plus the specialization on top. Somewhere along the way from CDI 1.0 to CDI 2.0 there we discussions about how exactly should an application behave in case that there is a CDI specialization but:
- Visibility restrictions imply that certain sub-deployment cannot "see" the specialized bean but could see the non-specialized one
- Very likely there were also fixes for this in between Weld 1 and Weld 3 and therefore in between EAP 6.4 and EAP 7.2 but that is of minor importance here
- In your case, this visibility limitation exists between ejbmodule.jar and warmodule.war where the EJB jar cannot see what's inside WAR
- CDI specification requires that specialization completely disables the original bean
- You can read on enabled and disabled beans more here in the spec
- In your case, presence of WebApplicationBean disables DefaultApplicationBean effectively eliminating it
From the above description I hope it is clearer what the issue is. The specialization eliminates the original bean but the EJB jar has restricted visibility and cannot see the replacement for DefaultApplicationBean hence you get unsatisfied dependency exception. As an evidence that this is intended behavior by specification, you can look at this CDI TCK test that captures a similar scenario with limitations on visibility. Take a glance at its javadoc for how the deployment looks like. Therefore the conclusion is that this is an intended behavior and not a bug. Here are some CDI issues that mention this or very similar scenarios, feel free to browse them:
If you want to fix this in your application, the proper way would be to extract WebApplicationBean into the shared lib common.jar. Apparently you intended for that bean to be visible from all modules, so placing it in a shared library seems only logical. |