Resource loading fails in Tomcat when Spring Boot is loaded from the common class loader

[ilinas]

Hello there. We have recently attempted to upgrade to Spring Boot 2.3.0 (and then 2.3.1), but unfortunately class loader changes made in #20900 broke our deployment.

We deploy as a skinny WAR (only the application JAR inside WAR) on Tomcat 8.5 where all the libraries are loaded via Tomcats Common class loader (JARs in $CATALINA_HOME/lib). Technically we should be using the Shared class loader, but oh well. We are doing this because we have hundreds of such deployments, so memory usage and disk space is a consideration.

Since #20900 Spring Boot can no longer load resources (like application.properties) if it itself has been loaded by Tomcats Common class loader. Including Spring, Spring Boot, and all other libraries that use Spring annotations inside the WAR file seems to solve the issue, but that is a lot of duplication in our case.

I am not sure if this qualifies as a bug per se, but this is a significant change in behavior, and we are unsure how to best address it?

[wilkinsona]

Thanks for the report and sorry for the inconvenience. The change in behaviour that you have seen wasn't anticipated and was unintended.

If I've understood your description of the problem that you are now facing correctly, I think there may have been a bug in 2.2.x as well. I'll try to explain.

Prior to #20900, the statically referenced DefaultResourceLoader would, when it's being instantiated, capture the TCCL at that time. I expect that this would be a webapp-specific ClassLoader. With DefaultResourceLoader loaded by the common class loader, this would then leak the webapp class loader if its webapp was undeployed.

Do you ever have applications a lifecycle that's shorter than that of the Tomcat instance to which they have been deployed?

[ilinas]

No, we deploy all applications and then start Tomcat. It is also all the same application, just running different configurations.

Wouldn't the actual fix be using the TCCL and not storing it? You really cannot make assumptions about which class loader a particular class is loaded by. Now with 2.3.x you have to make sure that all Spring components and all application components referencing Spring annotations have to be loaded by the same class loader. Which in case of Tomcat gives so many possibilities to get it wrong.

[ilinas]

On a closer look, I think the implementation in 2.2.x was correct. ClassLoader in DefaultResourceLoader is only stored if it is explicitly set via DefaultResourceLoader(@Nullable ClassLoader classLoader) or setClassLoader(@Nullable ClassLoader classLoader). Otherwise ClassLoader getClassLoader() is called which returns ClassUtils.getDefaultClassLoader(). I cannot see how that would cause the ClassLoader to leak.

Or rather I understand the concern, if one sets the ClassLoader explicitly, but from what I can see, the no-parameter new DefaultResourceLoader() is the safe one.

[wilkinsona]

In Spring Framework 5.2.x (which is the version that Spring Boot 2.2 and 2.3 use), DefaultResourceLoader() captures the ClassLoader at construction time. This creates the potential for a leak. The behaviour of DefaultResourceLoader() was changed in Spring Framework 5.3 to use the TCCL that's in place at the time of resource access.

We'll have to consider making a change like this in Boot. We rejected it previously due to the potential for a larger than wanted change in behaviour, however that didn't consider the situation that you are in.

[ilinas]

I see, yes. I was looking at Spring Framework 5.3. Sorry for the confusion.