Skip to content
This repository has been archived by the owner on Sep 2, 2023. It is now read-only.

could not get type for name org.springframework.web.servlet.mvc.method.annotation.ResponseEntityExceptionHandler from any class loader #132

Open
kauphylover opened this issue Jan 10, 2019 · 17 comments

Comments

@kauphylover
Copy link

kauphylover commented Jan 10, 2019

Spring boot version 2.1.1
Java 11
Gradle 5.0
Plugin version 1.0.6

Here's a Gradle scan that shows the error - https://gradle.com/s/m43exduyc4abg

@gigaSproule
Copy link
Owner

gigaSproule commented Feb 4, 2019

I can't see anything obviously wrong other than you may not have it in the classpath.

@mjparme
Copy link

mjparme commented Feb 6, 2019

I am having these issues too. Tons of "could not get type for name" for spring classes as well as classes generated from annotation processors.

@gigaSproule
Copy link
Owner

Just looking at the line that is throwing the exception, it should be looking for either @Api or @RestController and in a specific location, as you are providing packages. Not sure why it's complaining about some other class.

Are you both using java 11? In case that's the cause as it's reflection logic related.

@mjparme
Copy link

mjparme commented Feb 6, 2019

Yeah, it is definitely the reflection code complaining. I am using Java 8.

Works fine with Gradle 4.10 and 1.0.0 of this plugin.

Have to use a newer version of the plugin because of classesDir being removed from Gradle 5 (guess it is classesDirs now). So attempted to use 1.0.6 of the plugin with Gradle 5 and now I get this error. I get the same errors if I use 1.0.6 with Gradle 4.10.

could not get type for name org.springframework.security.acls.model.MutableAclService from any class loader
org.reflections.ReflectionsException: could not get type for name org.springframework.security.acls.model.MutableAclService
        at org.reflections.ReflectionUtils.forName(ReflectionUtils.java:390)
        at org.reflections.Reflections.expandSuperTypes(Reflections.java:381)
        at org.reflections.Reflections.<init>(Reflections.java:126)
        at org.reflections.Reflections.<init>(Reflections.java:168)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)

@gigaSproule
Copy link
Owner

Are you specifying the packages property? If so, what is it and where are your annotated classes? Also, @mjparme what is the relationship between MutableAclService and your annotated classes?

@mjparme
Copy link

mjparme commented Feb 21, 2019

Also, @mjparme what is the relationship between MutableAclService and your annotated classes?

@gigaSproule MutableAclService is found in a dependency of my code, it isn't directly referenced by my annotated class. (which makes this even more odd).

My locations only includes a single package, and that is my top-level package of all my code com.foo (foo isn't its real name of course)

@mjparme
Copy link

mjparme commented Feb 21, 2019

@gigaSproule FWIW, I get that error "could not get type for name...from any classloader" for pretty much every class my code references that are in my dependencies, here is another example:

could not get type for name com.github.benmanes.caffeine.cache.CacheLoader from any class loader

This includes classes that share my top-level package name but are in a dependent jar.

@mjparme
Copy link

mjparme commented Feb 22, 2019

I have created a test spring boot application that recreates the problem. Just extract the project, cd into the project and execute ./gradlew generateS you will see it complain:

could not get type for name org.springframework.boot.web.support.SpringBootServletInitializer from any class loader

What is interesting is if you run it a couple more times it will eventually work. But if you run ./gradlew clean you can recreate the problem again. This behavior (where it works after a couple of times) does not occur on my real project were I am experiencing the issue. So I am unsure I am recreating the exact problem.
bugtest.tar.gz

@kauphylover
Copy link
Author

@gigaSproule yes, I'm using Java 11. If it's reflection related, is there something I can do to overcome the issue? Let me know if you want the source code for this.

Just looking at the line that is throwing the exception, it should be looking for either @Api or @RestController and in a specific location, as you are providing packages. Not sure why it's complaining about some other class.

Are you both using java 11? In case that's the cause as it's reflection logic related.

@aanno2
Copy link

aanno2 commented Mar 20, 2019

I have the same problem as well. In some cases I could fix it with adding the (missing?!?) dependency to the buildscript classpath.

I'm working on a project with spring-cloud at the moment, where I'm using openfeign. The swagger-gradle-plugin has the problem on every feign client (interface), also when I'm using Java 8.

I wonder if adding an option to set the classpath (from a gradle configuration) would help.

@aanno2
Copy link

aanno2 commented Mar 21, 2019

I looked a bit more into my openfeign problem. Openfeign interfaces were under (package) web.rest.feign and the plugin is configure with locations = ["web.rest"].

When I move the Openfeign package to web.feign the error is gone. I suspect that this is because it is no more part of the plugin locations.

@GrafDiffusore
Copy link

GrafDiffusore commented Jun 4, 2019

Getting issue similar to above with 1.0.6 plugin ver, on JDK 1.8.202 (Azul).
Lots of warns/errors like:

could not get type for name com.foo.SecurityController from any class loader
org.reflections.ReflectionsException: could not get type for name com.foo.SecurityController
        at org.reflections.ReflectionUtils.forName(ReflectionUtils.java:390)
        at org.reflections.Reflections.expandSuperTypes(Reflections.java:381)
        at org.reflections.Reflections.<init>(Reflections.java:126)

Mentioning seemingly random classes from jars on classpath.
In the end, swagger.json is present, but due to these errors I'm not sure if it's correct.

Seems like as soon as any package specified in locations appears inside any jar on classpath, these errors will appear.

@mjparme
Copy link

mjparme commented Jun 24, 2019

Seems like as soon as any package specified in locations appears inside any jar on classpath, these errors will appear.

This actually appears to be the trigger for the problem...if I get a chance I might take another look at the source armed with this newfound piece of info.

@jonnii
Copy link

jonnii commented Sep 20, 2019

We recently ran into a similar problem to this and managed to fix it by adding the classes to the Gradle build class path. It was triggered when we added an interface to one of our resource models:

class Resource {
    data class Foo(....) : MyInterface
}

interface MyInterface

We are using Kotlin, but checking the generated byte code everything looked fine at a first glance. It was weird that the plugin could fine Foo before the change but not MyInterface which was in the same package...

@zwift-mark
Copy link

zwift-mark commented Nov 12, 2019

Experienced similar issue:

could not get type for name org.springframework.boot.web.servlet.error.ErrorController from any class loader
org.reflections.ReflectionsException: could not get type for name org.springframework.boot.web.servlet.error.ErrorController

Addressed issue by applying the same approach as @jonnii

build.grade:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath "org.springframework.boot:spring-boot:2.1.8.RELEASE"
    }
}

@mrsarm
Copy link

mrsarm commented Feb 13, 2020

Check the workaround here #158 (comment) that solves the issue

@gnavalesi-navent
Copy link

gnavalesi-navent commented Dec 3, 2020

I've been having this problem with different versions of the plugin, and different versions of spring-boot. Usually the workaround in #158 comment fixed the problem, but this time it didn't work. The classloader couldn't find any of my classes, but the plugin configuration was correct and the classes in the package configured were only POJOs and basic Controllers.

I've ended modifying the workaround to add the main classes to the classloader and it worked.

Java Version: 11.0.4 zulu
Spring Boot Version: 2.3.5.RELEASE
Gradle Version: 6.7
Swagger Gradle Plugin Version: 1.0.14

task fixGenerateSwaggerDocumentation {
    doLast {
        configurations.compileClasspath.resolve()
                .collect { it.toURI().toURL() }
                .each { buildscript.classLoader.addURL it }

        sourceSets.main.output.files
                .collect { it.toURI().toURL() }
                .each { buildscript.classLoader.addURL it }
    }
}

generateSwaggerDocumentation.dependsOn fixGenerateSwaggerDocumentation

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants