When using Jetty, filters, listeners, and servlets are not initialized with the same thread context classloader

[wilkinsona]

See #37638 for background. https://github.com/wilkinsona/spring-boot/tree/gh-37649 adds a test for all three servlet containers (Jetty, Tomcat, and Undertow). It only fails with Jetty.

[larsgrefer]

I've dug a little deeper to find out why this only affected me in 3.2.x but not in 2.7.x:

In my tests with 2.7.x, the classloader is always a jdk.internal.loader.ClassLoaders.AppClassLoader because Jetty never created a dedicated webapp classloader.

Jetty 9:

https://github.com/eclipse/jetty.project/blob/2691ad070b5a7e571653d6eee31317635341b87b/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebAppContext.java#L464-L470

Jetty 12:

https://github.com/eclipse/jetty.project/blob/27865d29b4b702ccf9c5dc00fd1a5f11cba4b0ce/jetty-ee10/jetty-ee10-webapp/src/main/java/org/eclipse/jetty/ee10/webapp/WebAppContext.java#L437-L441

In both cases, (Spring Boot 2.7 and 3.2) an explicit classloader is set in org.springframework.boot.web.embedded.jetty.JettyServletWebServerFactory#configureWebAppContext.

Jetty 9 is happy with the classloader provided by JettyServletWebServerFactory#configureWebAppContext.

Jetty 12 on the other hand checks if the provided classloader is an instance of WebAppClassloader (which it is not) and thus creates an explicit WebAppClassloader which then causes the problem described in #37638

In the unit test you have built, the JettyServletWebServerFactory has no resourceLoader set, so no explicit classloader is set for the WebAppContext. This causes Jetty 9 to create a separate WebAppClassloader and explains why in your tests Jetty 9/Boot 2.7 is affected and in my tests only Jetty 12/Boot 3.2 is affected.