`jetty-ee8-maven-plugin` attempts to load default configurations twice, precluding use of custom class loader in `WebAppContext`

[basil]

trafficstars

Jetty version(s) 12.0.8

Jetty Environment EE8

Java version/vendor (use: java -version)

openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-122.04.1)
OpenJDK 64-Bit Server VM (build 17.0.10+7-Ubuntu-122.04.1, mixed mode, sharing)

OS type/version Ubuntu 22.04.4 LTS x86_64

Description

Suppose jetty-ee8-maven-plugin is used with an instance of WebAppClassLoader set as the WebAppContext's class loader (rather than the default Maven realm class loader), as in https://github.com/jenkinsci/maven-hpi-plugin/blob/399e311e79235712e0eed9ff99ed7a2daac7fe4e/src/main/java/org/jenkinsci/maven/plugins/hpi/RunMojo.java#L795. Then when ServerSupport.configureDefaultConfigurationClasses(server) is called from JettyEmbedder#configure, all is well, since the context class loader is not the WebAppClassLoader and has access to server classes from which to load the configurations. But when we later get to ContextHandler.CoreContextHandler#doStart, the thread's context class loader is set to the WebAppContext's class loader, and when we get to WebAppContext#preConfigure and then to WebAppContext#loadConfigurations we will now again call WebAppContext#newConfigurations, which will now fail because the WebAppClassLoader does not have access to the requisite server classes from which to load the configuration.

I was able to work around the problem in https://github.com/jenkinsci/maven-hpi-plugin/blob/399e311e79235712e0eed9ff99ed7a2daac7fe4e/src/main/java/org/jenkinsci/maven/plugins/hpi/RunMojo.java#L617-L623, but this seems like a bug in jetty-ee8-maven-plugin. I suggest reusing the default configuration and not trying to load it a second time.

This bug was introduced after Jetty 10.0.20, since we are not experiencing it on that release but are experiencing it on 12.0.8.

How to reproduce?

Remove the workaround described above, build maven-hpi-plugin at the prototype branch I linked to above, and then execute mvn hpi:run from a Jenkins plugin using the abovementioned build.