Devtools: Same class with different classloader causing NoSuchBeanDefinitionException

[cemo]

@philwebb I have started to check our applications and came across an issue. (Sorry if It is already fixed)

Short description: My applications can not find some of beans when application starts.

Detailed description: I have debugged and found that If a class is loaded with two different class loader, the java.lang.Class#isAssignableFrom seems can not handle correctly. This is causing a problem in org.springframework.util.ClassUtils#isAssignable which is used for bean comparison. As a result a bean not found exception is raised.

I have checked each class and noticed that classes are loaded by AppClassLoader and RestartClassLoader.

This bean is registered by @Import configuration class. Spring Framework is registering beans with AppClassLoader but classes of other beans are loaded by RestartClassLoader.

[cemo]

I have also tried with 1.3.0.BUILD-SNAPSHOT which is also causing an exception.

[philwebb]

Do you have a sample application we could try? Usually Spring will use the context classloader to load beans (which should be the RestartClassLoader but we have seen some problems when Class.forName is used.

[cemo]

Sorry @philwebb I was on vacation. I am trying to understand how this whole stuff is working. I will let you know details.

[sergiorc]

I have found the same issue using:

spring-boot 1.3.0-BUILD-SNAPSHOT
spring-dev-tools 1.3.0-BUILD-SNAPSHOT
spring-hateoas 0.18.8-BUILD-SNAPSHOT

To reproduce the issue, spring-hateoas project MUST be open in your IDE workspace (eclipse in my case).

Spring HATEOAS HypermediaSupportBeanDefinitionRegistrar class is creating a DelegatingRelProvider with "_relProvider" name:

        BeanDefinitionBuilder delegateBuilder = BeanDefinitionBuilder.rootBeanDefinition(DelegatingRelProvider.class);
        delegateBuilder.addConstructorArgValue(registryBeanDefinition);

        AbstractBeanDefinition beanDefinition = delegateBuilder.getBeanDefinition();
        beanDefinition.setPrimary(true);
        registry.registerBeanDefinition(DELEGATING_REL_PROVIDER_BEAN_NAME, beanDefinition);

But it doesn't qualify as a org.springframework.hateoas.RelProvider instance in org.springframework.boot.autoconfigure.hateoas.HypermediaAutoConfiguration$HypermediaConfiguration$HalObjectMapperConfiguration:

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.boot.autoconfigure.hateoas.HypermediaAutoConfiguration$HypermediaConfiguration$HalObjectMapperConfiguration': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private org.springframework.hateoas.RelProvider org.springframework.boot.autoconfigure.hateoas.HypermediaAutoConfiguration$HypermediaConfiguration$HalObjectMapperConfiguration.relProvider; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [org.springframework.hateoas.RelProvider] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true), @org.springframework.beans.factory.annotation.Qualifier(value=_relProvider)}
    at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:334)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)

Going a bit deeper, I've found the same case that @cemo.
When testing if DelegatingRelProvider.class is assignable to RelProvider.class (org.springframework.util.ClassUtils.isAssignable) the return is false because classloaders are distinct.

DelegatingRelProvider classloader is RestartClassLoader.
RelProvider classloader is AppClassLoader.

Closing spring-hateoas in the IDE, or removing spring-dev-tools from classpath prevents any error.
I suppose the issue can be reproduced with any other project instead spring-hateoas.

[philwebb]

@sergiorc I've hit the same issue when developing devtools. It's to do with the way that the split classloader is created. Since eclipse will be exposing spring-hateos as an exploded application devtools thinks it is a candidate for monitoring.

We have some logic in ChangeableUrls that detects some Spring Jars, we could potentially extend this but it's a bit tricky to know if a jar is a Spring library or not (only going on the name).

The easiest workaround for now is to disable inter-project resolution in eclipse or simply work on spring-hatoes in a different workspace.

[philwebb]

@cemo are you still having the issue? Did you have other Spring projects open in your workspace?

[cemo]

I have created a sample application with our codebase with not all of our modules. This application was working properly but when I started run at production application, I am having same issue. I hope that I will give a try with latest beta and narrow issue.

[sergiorc]

@philwebb
But, this issue will only happen with spring libraries? I supposed the problem is comparing any class between both classloaders (AppClassLoader and RestartClassloader).

[snicoll]

It will happen indeed with any library that deserialize content. Caching libraries, in particular, are affected.

[sergiorc]

Ok, thanks by the info

[jceloi]

Just to confirm it, I've experienced the same problem with spring-security oauth2 jdbc store, which serializes objects.

For instance when inspecting the classloaders of my object and the class as used within the application I get those two :

• sun.misc.Launcher$AppClassLoader@15316f2 <- deserialized
• org.springframework.boot.devtools.restart.classloader.RestartClassLoader@c8de43 <- currently executing code

Hence the classcast with my class not being able to be cast to itself.