IllegalStateException: CDI is not available during EE 10 Platform TCK ejb30.lite.nointerface.descriptor.Client.invokeRemovedStateful_from_ejbembed test on JDK11

[scottmarlow]

During EE 10 (Full) Platform TCK testing we are seeing the below failure (see root/vi/glassfish7/glassfish/domains/domain1/logs/server.log in https://ci.eclipse.org/jakartaee-tck/job/jakartaee-tck/job/master/1758/artifact/ejb30_lite_nointerface-results.tar.gz):

[2022-04-24T08:45:06.998+0000] [glassfish 7.0] [INFO] [faces.config.listener.version] [jakarta.enterprise.resource.webcontainer.faces.config] [tid: _ThreadID=80 _ThreadName=AutoDeployer] [timeMillis: 1650789906998] [levelValue: 800] [[
  Initializing Mojarra 4.0.0-M6 for context '/ejblite_nointerface_descriptor_ejblitejsf_vehicle_web']]

[2022-04-24T08:45:07.089+0000] [glassfish 7.0] [SEVERE] [] [jakarta.enterprise.resource.webcontainer.faces.config] [tid: _ThreadID=80 _ThreadName=AutoDeployer] [timeMillis: 1650789907089] [levelValue: 1000] [[
  Critical error during deployment:
java.lang.IllegalStateException: CDI is not available
        at com.sun.faces.util.Util.getCdiBeanManager(Util.java:1493)
        at com.sun.faces.el.ELUtils.addCDIELResolver(ELUtils.java:192)
        at com.sun.faces.el.ELUtils.buildFacesResolver(ELUtils.java:164)
        at com.sun.faces.application.ApplicationAssociate.initializeELResolverChains(ApplicationAssociate.java:416)
        at com.sun.faces.application.applicationimpl.ExpressionLanguage.performOneTimeELInitialization(ExpressionLanguage.java:144)
        at com.sun.faces.application.applicationimpl.ExpressionLanguage.getELResolver(ExpressionLanguage.java:89)
        at com.sun.faces.application.ApplicationImpl.getELResolver(ApplicationImpl.java:200)
        at com.sun.faces.el.ELContextImpl.<init>(ELContextImpl.java:60)
        at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:202)
        at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5051)
        at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:563)
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:5627)
        at com.sun.enterprise.web.WebModule.start(WebModule.java:511)
        at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:877)
        at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:144)
        at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:134)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:858)
        at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:644)
        at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2021)
        at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1667)
        at com.sun.enterprise.web.WebApplication.start(WebApplication.java:82)
        at org.glassfish.internal.data.EngineRef.start(EngineRef.java:98)
        at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:267)
        at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:328)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:480)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:199)
        at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:467)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:516)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:512)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/javax.security.auth.Subject.doAs(Subject.java:361)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:511)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:542)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:534)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/javax.security.auth.Subject.doAs(Subject.java:361)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:533)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1441)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1823)
        at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:140)
        at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:573)
        at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:460)
        at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:388)
        at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:379)
        at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:209)
        at java.base/java.util.TimerThread.mainLoop(Timer.java:556)
        at java.base/java.util.TimerThread.run(Timer.java:506)
]]

Is ^ a Mojarra issue or more of an integration with CDI issue?

[starksm64]

The problem is the contents of the war and the change in default behavior for CDI beans. The ejblite_nointerface_descriptor_ejblitejsf_vehicle_web.war has a faces-config.xml that defines a managed-bean, but the corresponding class com.sun.ts.tests.ejb30.lite.nointerface.descriptor.Client has no bean defining annotations. If I add an empty beans.xml to the war, it deploys fine.

How is the faces-config.xml generated for this war? I can't see how to determine where managed-beans are used that don't have a beans.xml file in the ejb30/lite source tree.

[arjantijms]

A little extra background; com.sun.faces.config.ConfigureListener is in the stack because (likely) faces content has been encountered. This listener is most often dynamically added by Mojarra.

If there are zero beans found, Weld on its turn abort its initialisation, which has as a result that the bean manager can't be obtained, prompting Mojarra to say "CDI is not available".

[starksm64]

@arjantijms correct, this is a war with faces content. All similar wars need to be updated to address the changes in CDI default scanning behavior, but I don't see how the WEB-INF/faces-config.xml is generated for these wars to determine which are using managed-beans.

[scottmarlow]

How is the faces-config.xml generated for this war?

I think the source xml is from https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/common/vehicle/ejblitejsf/faces-config.xml and is referenced from various tests that need it indirectly via ant scripting.

If we need to add an empty beans.xml, I think at least file https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/bin/xml/ts.vehicles.xml would need a change.

cd jakartaee-tck
grep -rli faces-config.xml
src/com/sun/ts/tests/common/vehicle/ejblitejsf/ejblitejsf_vehicle_web.xml
src/com/sun/ts/tests/ejb30/lite/packaging/war/xmloverride/ejbref/ejblitejsf_vehicle_web.xml
src/com/sun/ts/tests/ejb30/lite/packaging/war/enventry/ejblitejsf_vehicle_web.xml
src/com/sun/ts/tests/ejb30/common/lite/EJBLiteClientBase.java
src/com/sun/ts/tests/ejb30/common/war-import.xml
bin/xml/ts.war.xml
bin/xml/ts.vehicles.xml

Would the empty beans.xml need to include bean-discovery-mode="all"?

[scottmarlow]

More specifically, I think the empty beans.xml would need to be added via the ejblitejsf handling that starts at https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/bin/xml/ts.vehicles.xml#L450 by copying the faces-config.xml into the deployment archive.

[scottmarlow]

Since managed beans are removed now via jakartaee/faces#1547, should Faces 4.0 implementations fail to deploy applications with faces-config.xml that specify managed beans?

[scottmarlow]

The new Faces TCK has resolved the same failure by adding an empty beans.xml as suggested in jakartaee/faces#1600 (comment), so I think we can proceed to add an empty beans.xml (with bean-discovery-mode="all").

[scottmarlow]

I will open a Platform TCK issue for addressing and soon close this issue. Thanks all!

[scottmarlow]

Since managed beans are removed now via jakartaee/faces#1547, should Faces 4.0 implementations fail to deploy applications with faces-config.xml that specify managed beans?

We didn't answer this question yet but I am thinking that Mojarra is not likely trying to process the jakarta.annotation.ManagedBean classes that might be listed in the faces-config.xml.

I'm looking more closely at the failure to see if the eclipse-ee4j/mojarra@808d9ed change is correct for Faces 4.0.

Opened eclipse-ee4j/mojarra#5080 for ^

[scottmarlow]

I'm closing this due to Faces 4.0 SPEC having a hard requirement that all Faces 4.0 application deployments to be configured to enable CDI. We will deal with that in the Platform TCK, at least that is now the plan.