Annotation scanning in enclosing class hierarchy results in NoClassDefFound #24136
Comments
Custom starterConsuming app |
|
I hvae made some debug and found some strange thing. In |
|
@OLPMO I have done the same debugging and that call to loadClass("com.example.demolib.DemoAutoConfiguration$DemoWebFluxConfiguration")is a result from the call on native method class com.example.demolib.DemoAutoConfiguration$DemoWebMvcConfiguration#getDeclaringClass0()which as expected, first loads its outer class com.example.demolib.DemoAutoConfiguration, but that in turn causes the load on its nested static class com.example.demolib.DemoAutoConfiguration$DemoWebFluxConfigurationwhich then fails. So it seems like the "safety" of the ASM processed annotation metdata (in this case |
spring-projects-issues
added
the
status: waiting-for-triage
rstoyanchev
added
in: core
|
@jhoeller, this does look like a regression, so I've scheduled tentatively for 5.2.3. |
|
I'm actually not certain that this is a regression. Rather, it appears to me that the cause is this change in Spring Boot 2.2. Specifically, prior to that commit, Spring Boot did not search for @philwebb, what are your thoughts on this? |
@bono007, the class that kicks this off is |
|
In any case,
Thus, we should probably start using that in the newly introduced |
|
I wonder if the |
That would be one option: to introduce a try-catch around the enclosing class lookup. However, I think we will have to reintroduce use of
Yes, we'd ideally like to avoid that. |
…rategy Prior to this commit, the enclosing class was always eagerly loaded even if the annotation search strategy was not explicitly TYPE_HIERARCHY_AND_ENCLOSING_CLASSES. See gh-24136
sbrannen
changed the title
sbrannen
added
type: bug
…defensive Prior to this commit, when searching for annotations using the TYPE_HIERARCHY_AND_ENCLOSING_CLASSES strategy an exception could be thrown while attempting to load the enclosing class (e.g., a NoClassDefFoundError), thereby halting the entire annotation scanning process. This commit makes this search strategy defensive by logging exceptions encountered while processing the enclosing class hierarchy instead of allowing the exception to halt the entire annotation scanning process. The exception handling is performed by AnnotationUtils.handleIntrospectionFailure() which only allows an AnnotationConfigurationException to propagate. See gh-24136
|
@sbrannen - nice work! Yep - that does it. I ensured I could still reproduce it.
I then added snapshot repo and version to my pom.xml as such and got clean startup. <dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>5.2.3.BUILD-SNAPSHOT</version>
</dependency>
<repositories>
<repository>
<id>repository.springframework.maven.snapshot</id>
<name>Spring Framework Maven Snapshot Repository</name>
<url>http://repo.spring.io/snapshot/</url>
</repository>
</repositories>
You can see the new logging about the failure as per 6e21b19.
|
|
@bono007, that's great news! I'm glad to hear that solved the issue for you, and thanks for the detailed feedback. 👍 In light of that, I will close this issue and open a new issue to address potential regressions due to lack of use of |
Version:
2.2.[0|1].RELEASEContext:
Behavior in
2.1.x.RELEASEwas that the webflux gated config would be excluded and all was well.Behavior w/
2.2.x.RELEASEis startup fails w/ following:Starter snippet pom.xml
Starter auto-config
Consuming app pom.xml snippet
NOTE: If I comment out the
DemoWebMvcConfigurationthe conditional behaves and the webflux gated config is excluded and all is well. It seems that when they are both present the config properties annotation scan tries to load the classes.The text was updated successfully, but these errors were encountered: