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

[basil]

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.

[basil]

I found a slightly cleaner workaround in jenkinsci/maven-hpi-plugin@2c60a03 by overriding WebAppContext#configureClassLoader to return my WebAppClassLoader rather than calling WebAppContext#setClassLoader. This sets up the current thread's context class loader correctly, but I still think it is a (Jetty) bug that calling WebAppContext#setClassLoader results in a thread context class loader configuration that essentially breaks the startup process.

[janbartel]

@basil interesting re-use of the jetty maven plugin!

It's not doing the same thing twice: when ServerSupport.configureDefaultConfigurationClasses(server) is called, it is setting up the names of the configuration classes that will be used iff the WebAppContext instance has not had instances explicitly configured. Then in WebAppContext.loadConfigurations() we are creating the instances that will belong to this context. That is called from WebAppContext.preConfigure(), which in turn is called from WebAppContext.doStart(), where the classloader has not been set to the webapp classloader, at least not by WebAppContext itself. Are you saying the the jetty maven plugin is explicitly setting the classloader to the webapp classloader before this call, if so can you show me where?