Webfragments of a JSF application are not deployed via autodeploy folder

Technical Discussion
1

We are running payara 5 in an OpenShift Cluster where we use the Source-To-Image strategy. During the build phase the application image is copied into the autodeploy folder.

After starting the container we can see that the server starts the deployment of our application.
At a first glance everything looks fine. But we recognized that the deployed JSF application is not working correctly.

We found out that all web-fragments located in the /WEB-INF/lib directory will be ignored and the resources (like css or js files) are not available for the JSF application. A typical log message, we can see during deployment in your payara log file, looks like this:

2021-10-17T22:47:43.684+0200|WARNING|Payara 5.201|org.glassfish.grizzly.config.GenericGrizzlyListener|_ThreadID=20;_ThreadName=RunLevelControllerThread-1634503650671;_TimeMillis=1634503663684;_LevelValue=900;| Unable to construct HTTP/2 Addon java.lang.NoClassDefFoundError: org/glassfish/grizzly/npn/AlpnServerNegotiator at org.glassfish.grizzly.config.GenericGrizzlyListener.configureHttp2Support(GenericGrizzlyListener.java:806) .... ...... Caused by: java.lang.ClassNotFoundException: org.glassfish.grizzly.npn.AlpnServerNegotiator

The domain.xml file does not contain any das-config tag. I guess the following tag would be necessary for the deployment via the autodeploy folder:

<das-config dynamic-reload-enabled="true" autodeploy-enabled="true"></das-config>

Is this correct?

What else could be the reason that JSF web fragments are missing after deployment? EJBs and CDI beans seems to be deployed correctly.

2

Hi,

I guess it is a Payara Server version 5.201 which is depended on the Supported Platforms as the following: -

Supported Java Virtual Machines

The Payara Platform currently supports the following Java Virtual Machines:

Oracle JDK8 (u162+), Oracle JDK 11 (11.0.5+)

Azul Zulu JDK8 (u162+), Azul Zulu JDK 11 (11.0.5u10+)

OpenJDK JDK8 (u162+), OpenJDK 11 (11.0.5+)

TLS 1.3 is supported on JDK 8 with Azul Zulu 1.8.222+ only and all JDK 11 versions.

At the first glance, it may be a JDK version issue.

Moreover there is a closed issue at Payara GitHub, NoClassDefFoundError AlpnServerNegotiator · Issue #3138 · payara/Payara · GitHub , which is the similar to what we’ve faced now. It’s stating about the domain.xml of the newly created by version 5.201 and the earlier version, especially the -Xbootclasspath arguments which is different. If we copied the domain.xml from the older version, then it would be nice to try to create the new, fresh and clean domain by using the version 5.201 and use the diff tool to determine the difference.

Furthermore, there also is a closed issue from eclipse-ee4j /glassfish as startup issue in 5.1.0 · Issue #22736 · eclipse-ee4j/glassfish · GitHub which is about the similar issue and it’s stating about the JDK version as well.

Last but not least, there are few blog post about the version 5.201 and HTTP/2 support which may give us more information and may help us to investigate further as the following: -