SpringBoot Likely issues of incorrect classloader being used

I found additional places in the code that look like they likely could cause issues when an alternate classloader is used for a SpringApplication, but I have not actually experienced an issue yet.

https://github.com/spring-projects/spring-boot/blob/f06b784d6ea8f1faccf5b37b0a36905df4ac7fe7/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/env/SpringApplicationJsonEnvironmentPostProcessor.java#L161

https://github.com/spring-projects/spring-boot/blob/f06b784d6ea8f1faccf5b37b0a36905df4ac7fe7/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/json/JsonParserFactory.java#L39

https://github.com/spring-projects/spring-boot/blob/f06b784d6ea8f1faccf5b37b0a36905df4ac7fe7/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/reactor/DebugAgentEnvironmentPostProcessor.java#L44

https://github.com/spring-projects/spring-boot/blob/f06b784d6ea8f1faccf5b37b0a36905df4ac7fe7/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/BeanDefinitionLoader.java#L227

https://github.com/spring-projects/spring-boot/blob/f06b784d6ea8f1faccf5b37b0a36905df4ac7fe7/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/WebApplicationType.java#L67

https://github.com/spring-projects/spring-boot/blob/f06b784d6ea8f1faccf5b37b0a36905df4ac7fe7/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/WebApplicationType.java#L86

https://github.com/spring-projects/spring-boot/blob/f06b784d6ea8f1faccf5b37b0a36905df4ac7fe7/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/jdbc/DataSourceBuilder.java#L487

https://github.com/spring-projects/spring-boot/blob/f06b784d6ea8f1faccf5b37b0a36905df4ac7fe7/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/context/config/DelegatingApplicationContextInitializer.java#L73

https://github.com/spring-projects/spring-boot/blob/f06b784d6ea8f1faccf5b37b0a36905df4ac7fe7/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/context/config/DelegatingApplicationListener.java#L82

https://github.com/spring-projects/spring-boot/blob/f06b784d6ea8f1faccf5b37b0a36905df4ac7fe7/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/context/properties/ConfigurationPropertiesScanRegistrar.java#L103

https://github.com/spring-projects/spring-boot/blob/f06b784d6ea8f1faccf5b37b0a36905df4ac7fe7/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/BeanDefinitionLoader.java#L195

Comment From: philwebb

Also

Similar to issues #27071 and #27072 the YamlPropertySourceLoader does not use an alternate classloader if one is provided to the SpringApplication. The problem can be found here https://github.com/spring-projects/spring-boot/blob/f06b784d6ea8f1faccf5b37b0a36905df4ac7fe7/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/env/YamlPropertySourceLoader.java#L46.

Comment From: wilkinsona

Thanks for this. While a number of these look similar to #27133, there are others where someone may be relying on the current behaviour. Until someone reports a concrete problem we'd prefer to leave things as they are and avoid the risk of introducing a subtle regression.

Comment From: ArthurEnglebert

Hello, not sure if related, but today, we got a problem related to autowiring features only occuring when using devtools. The autowiring works correctly if the application is launched inside a tomcat, or as a runnable jar. On the other hand, when used with the devtools restart system (spring-boot:run / intellij spring-boot configuration), the autowiring fails to map the correct beans together.

Here is what I found so far (sorry for the hidden information, as this is a company application, i cannot show you some parts of the code).

bug-classloader_LI

Backstory of the code is : Standard autowiring feature (via @Autowired on a property inside a @Service class scanned). the interface maps to a bean declared in a @AutoConfig which is loaded (we can see it in the beanfactory).

But in the process, when the DefaultListableBeanFactory tries to find matching bean corresponding to the property interface, it fails to do so : The exact problem is org.springframework.beans.factory.support.AbstractBeanFactory#isTypeMatch(java.lang.String, org.springframework.core.ResolvableType)

This will find both the same classes but loaded in a distinct classloader (and thus the call org.springframework.util.ClassUtils#isAssignable return false)

Comment From: wilkinsona

@ArthurEnglebert That’s unrelated to the changes proposed in this issue. Your problem sounds like it’s related to Devtools’ split class loader which will load frequently-changing application classes in its restart class loader and the application’s dependencies in the system class loader. I can’t say more about what may be causing your problem from what you’ve shared this far. If you’d like us to take another look, please open a new issue and provide a minimal sample (it doesn’t have to be your actual application) that reproduces the problem.

Comment From: ArthurEnglebert

@wilkinsona well, it's probably linked to some shady underlying system IntelliJ is using as it was the very first time we had the error, and it's working well & as intented for other apps (using the same autoconfig). If I ever get the time to cleanup the code and make a valid sample reproducing the problem, I will post that as a new issue.