Likely issues of incorrect classloader being used

[jaminh]

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.

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/env/SpringApplicationJsonEnvironmentPostProcessor.java

Line 161 in f06b784

if (ClassUtils.isPresent(SERVLET_ENVIRONMENT_CLASS, null)) {

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/json/JsonParserFactory.java

Line 39 in f06b784

if (ClassUtils.isPresent("com.fasterxml.jackson.databind.ObjectMapper", null)) {

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/reactor/DebugAgentEnvironmentPostProcessor.java

Line 44 in f06b784

if (ClassUtils.isPresent(REACTOR_DEBUGAGENT_CLASS, null)) {

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/web/embedded/jetty/SslServerCustomizer.java

Line 131 in f06b784

return ClassUtils.isPresent("org.eclipse.jetty.alpn.server.ALPNServerConnectionFactory", null);

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/BeanDefinitionLoader.java

Line 227 in f06b784

return ClassUtils.isPresent("groovy.lang.MetaClass", null);

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/WebApplicationType.java

Line 67 in f06b784

if (!ClassUtils.isPresent(className, null)) {

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/WebApplicationType.java

Line 86 in f06b784

return ClassUtils.resolveClassName(target, null).isAssignableFrom(type);

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/jdbc/DataSourceBuilder.java

Line 487 in f06b784

return (V) ClassUtils.resolveClassName(value, null);

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/validation/MessageInterpolatorFactory.java

Line 77 in f06b784

Class<?> interpolatorClass = ClassUtils.resolveClassName(fallback, null);

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/context/config/DelegatingApplicationContextInitializer.java

Line 73 in f06b784

Class<?> initializerClass = ClassUtils.forName(className, ClassUtils.getDefaultClassLoader());

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/context/config/DelegatingApplicationListener.java

Line 82 in f06b784

Class<?> clazz = ClassUtils.forName(className, ClassUtils.getDefaultClassLoader());

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/context/properties/ConfigurationPropertiesScanRegistrar.java

Line 103 in f06b784

register(registrar, ClassUtils.forName(className, null));

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/web/embedded/jetty/JasperInitializer.java

Line 57 in f06b784

Class<?> initializerClass = ClassUtils.forName(className, null);

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/web/servlet/support/ErrorPageFilter.java

Line 306 in f06b784

collection.add(ClassUtils.forName(className, null));

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/BeanDefinitionLoader.java

Line 195 in f06b784

load(ClassUtils.forName(resolvedSource, null));

[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

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/env/YamlPropertySourceLoader.java

Line 46 in f06b784

if (!ClassUtils.isPresent("org.yaml.snakeyaml.Yaml", null)) {

.

[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.

[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).

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)

[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.

[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.