specify explicit CDI bean discovery mode

[scottmarlow]

Signed-off-by: Scott Marlow smarlow@redhat.com

Related Issue(s)
jakartaee/cdi#500 change (see blog)
Quoting from the blog:

One notable change coming to CDI is the discovery mode of bean archives containing empty beans.xml. These were formerly treated as explicit bean archives (i.e. having discovery mode all) but beginning with CDI 4.0, they will be considered as implicit bean archives (discovery mode annotated).

In other words, if a class in such an archive is to be recognized as a bean, it needs to have at least one bean defining annotation. It can be a breaking change which is why this change also comes with a backward compatible switch - all CDI Full products have to contain an option that switches the behavior to how it worked in the past. The option is of course a temporary measure to ease transition and applications are encouraged to adapt their bean archives accordingly in the long term.

We can now ask what is bean defining annotations? To answer that, we can look at the CDI 3.0 Spec which states:

The set of bean defining annotations contains:
-     @ApplicationScoped, @SessionScoped, @ConversationScoped and @RequestScoped annotations,
-     all other normal scope types,
-     @Interceptor and @Decorator annotations,
-     all stereotype annotations (i.e. annotations annotated with @Stereotype),
-     and the @Dependent scope annotation.

Describe the change
The default Discovery Mode for empty beans.xml is implicit bean archives, so we need to switch to explicit bean archives mode.

https://jakarta.ee/specifications/cdi/3.0/jakarta-cdi-spec-3.0.html#bean_defining_annotations

[scottmarlow]

https://ci.eclipse.org/jakartaee-tck/job/10/job/eftl-jakartaeetck-run-100/9/ reproduced the failure that I saw locally that led to me creating the PR. The GlassFish server.log is contained here.

The exception that occurs is pasted below:

Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class com.sun.ts.tests.servlet.ee.platform.cdi.filter.TestFilter
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:328)
	at com.sun.enterprise.web.WebContainer.createFilterInstance(WebContainer.java:742)
	at com.sun.enterprise.web.WebModule.createFilterInstance(WebModule.java:1963)
	at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:215)
	at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:82)
	... 38 more
Caused by: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001408: Unsatisfied dependencies for type TCKTestBean with qualifiers @Default
  at injection point [BackedAnnotatedField] @Inject com.sun.ts.tests.servlet.ee.platform.cdi.filter.TestFilter.ttb
  at com.sun.ts.tests.servlet.ee.platform.cdi.filter.TestFilter.ttb(TestFilter.java:0)

	at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:83)
	at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:70)
	at org.jboss.weld.manager.BeanManagerImpl.fireProcessInjectionTarget(BeanManagerImpl.java:1214)
	at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:435)
	at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:306)
	at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:453)
	at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:406)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:312)
	... 42 more
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type TCKTestBean with qualifiers @Default
  at injection point [BackedAnnotatedField] @Inject com.sun.ts.tests.servlet.ee.platform.cdi.filter.TestFilter.ttb
  at com.sun.ts.tests.servlet.ee.platform.cdi.filter.TestFilter.ttb(TestFilter.java:0)

	at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:367)
	at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:285)
	at org.jboss.weld.bootstrap.Validator.validateProducer(Validator.java:414)
	at org.jboss.weld.injection.producer.InjectionTargetService.validateProducer(InjectionTargetService.java:36)
	at org.jboss.weld.manager.InjectionTargetFactoryImpl.validate(InjectionTargetFactoryImpl.java:153)
	at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:81)

[scottmarlow]

The remaining question is how does one grep for TCK source that will have this problem?

[scottmarlow]

The remaining question is how does one grep for TCK source that will have this problem?

Maybe search for beans.xml that doesn't have bean-discovery-mode.

[starksm64]

Any empty beans.xml deployment will need to be looked at for whether it should be updated to use the bean-discovery-mode="all", or look for @Inject usage and evaluate the bean being injected. In this com.sun.ts.tests.servlet.ee.platform.cdi package tree, the TCKTestBean and BeanManager are being injected, and the TCKTestBean could just be updated to use @ApplicationScoped to avoid having to change the other beans.xml files.

[starksm64]

I created a general issue for this and will make a pass at updating all CDI bean usage, #876

[scottmarlow]

Added @ApplicationScoped to TCKTestBean and tested via https://ci.eclipse.org/jakartaee-tck/job/jakartaee-tck-scottmarlow/job/servlet_explicit_cdi_archive_2/2/testReport which passed tests:

• com.sun.ts.tests.servlet.ee.platform.cdi.filter
• com.sun.ts.tests.servlet.ee.platform.cdi.listener
• com.sun.ts.tests.servlet.ee.platform.cdi.servlet