Hello,

I came across some classloading and dependency ambiguous resolution with the following structure :

• EAR
  • lib folder
    • common.jar
      • IApplicationBean.class (interface annotated @javax.enterprise.context.ApplicationScoped)
      • DefaultApplicationBean.class (implements IApplicationBean
  • ejbmodule.jar
    • SampleService (@Inject IApplicationBean)
  • warmodule.war
    • WebApplicationBean (extends DefaultApplicationBean and is annotated @javax.enterprise.inject.Specializes)
    • TestBean (@Inject IApplicationBean)

When using jboss EAP 6.4 (weld-core-1.1.34.Final / CDI 1.0 spec), injecting IApplicationBean bean anywhere in the application (including ejb module jar and inside the war) resolve the injectionpoint with the WebApplicationBean

This was somehow an issue where we would suspect to resolve DefaultApplicationBean inside the ejb module jar and WebApplicationBean inside the war module.

When using jboss EAP 7.2 (weld-core-impl-3.0.6.Final / CDI 2.0 spec) or wildfly 18 (weld-core-impl-3.1.2.Final / CDI 2.0 spec), the dependency resolution fail with the following :

WELD-001408: Unsatisfied dependencies for type IApplicationBean with qualifiers @Default at injection point [BackedAnnotatedField] @Inject private sample.testcase.SampleService.applicationBean

It looks like when scanning for available beans, if a @Specializes bean is found, every extended bean are removed from the list of available beans on a per-application basis and not on a per-module basis.

Then when the injection point resolution are made, there is no dependency available on for the ejbmodule as they have been eliminated by the bean discovery above.

This is unfortunately a feature which is used by deltaspike CDI extension and its JSF module and thus prevents us from upgrading to EAP 7 without applying the following (ugly ?) workaround :
Adding the war subdeployment to the ear dependency list in the jboss-deployment-structure resolved the issue