Assume the following class
and deployment structure:
In addition, we assume the standard accessibility layout, where web archives are isolated and both web archives have access to the shared library archive. Note that the beans.xml file, which is present in web1.war, web2.war and shared.jar is omitted in deployment structure diagrams.
The X bean is available for injection in both web1 and web2 applications.
Furthermore, let's assume that web1 introduces the following bean for its own purpose:
Now assume the following injection point:
If the injection point belongs to a bean bundled within web1.war, it should be injected with an instance of Y.
If the injection point belongs to a bean bundled within shared.jar, it should be injected with an instance of X (and not Y).
If the injection point belongs to a bean bundled within web2.war, it should intuitively be injected with X (because Y is not accessible). However, the specification says that:
A bean is said to be enabled if it is not specialized by any other enabled bean, as defined in Section 4.3, “Specialization”...
which X in this case is. As a result, the X bean is not enabled and the injection point would be unsatisfied if deployed within web2.war. This seems to be very counterintuitive. The fact whether a given bean can/cannot be injected due to specialization should be decided per module and not on the global enabled/disabled level.
The proposed fix is to make a bean available for injection in a given module
- if the bean is not specialized by another enabled bean or
- the bean is specialized by another enabled bean and the specializing bean is not available for injection in the given module.
It should also be clarified if container lifecycle events that are only fired for enabled beans (such ProcessBean and ProcessBeanAttributes) should or should not be fired for beans which are specialized in a certain module but are not in another module.