Configuration class implementing Provider interface throws StackOverflowError after upgrading to Java 7 [SPR-11830]

[spring-projects-issues]

Jakub Bochenski opened SPR-11830 and commented

Please see reference URL

---

Affects: 3.2.1

Reference URL: https://stackoverflow.com/questions/23931742

Issue Links:

• Periodic NoClassDefFoundError: FatalBeanException caused by StackOverFlowException [SPR-10261] #14894 Periodic NoClassDefFoundError: FatalBeanException caused by StackOverFlowException

Referenced from: commits 31f2f20

[spring-projects-issues]

Juergen Hoeller commented

From an initial glance at your StackOverflow posting:

First of all, it's unusual to have an @Configuration class implementing the Provider interface (which Spring separately supports for lazy lookup of target beans at injection points), with the get() implementation annotated as an @Bean method... This combination is not officially supported and may easily cause mis-interaction between the container, CGLIB, and your bean class. Is there a specific reason why you're doing this, and does it work if you get rid of the "implements Provider" declaration?

Also, note that we're not supporting outdated versions in the 3.2.x branch anymore. We're only going to try to reproduce this against 3.2.9 on our side, and we would strongly recommend to upgrade to that version on your side as well. There have been many bug fixes in that line in the meantime, including fixes for Java 7 and Java 8 compatiblity as well as a CGLIB and ASM upgrade, so it's really unfeasible to track such a specific bug eight maintenance versions behind in the 3.2.x branch there...

Juergen

[spring-projects-issues]

Jakub Bochenski commented

Thanks. It was indeed the Provider interface which was causing problems (or at least removing it fixed it).
The reason for using such construct is to make the class guice compatible at the same time.

This combination is not officially supported and may easily cause mis-interaction between the container, CGLIB, and your bean class.
Well I see a problem here: there is no mention in documentation that you should not implement Provider.

As for upgrading: unfortunately that's not something we can do overnight (regression testing etc.).

[spring-projects-issues]

Jakub Bochenski commented

PS. Just wanted to point out two peculiarities:

• this only happens for J7 and not J6
• we have ~20 @Configuration classes written like this and only this one was causing problems

[spring-projects-issues]

Juergen Hoeller commented

It's indeed strange that it only happens on Java 7. I suspect a problem with reflection over generated bridge methods, possibly in interaction with CGLIB's method interception. So there definitely is an issue here, and if not already fixed through related changes in recent Spring releases, we will research it and address it in the Spring Framework 4.1 line in any case.

As a further hint, it might also help to declare the class as a regular @Component instead of @Configuration. If you are not using cross-@Bean method calls within such a class, a simple stereotype does the job as well - and avoids CGLIB completely. We call these 'lite' configuration classes.

As for the documentation not mentioning that combination, well, there are plenty of feature combinations not mentioned and not officially supported. We're generally willing to support whatever people choose to use but I'm afraid we can't anticipate potential side effects for unexpected combinations.

Finally, I wouldn't drop in a new Spring Framework version without regression testing either. I was just suspecting that you're in such a testing phase anyway since you upgraded to Java 7, and a minor Spring Framework upgrade would go along with that rather easily.

Juergen

[spring-projects-issues]

Jakub Bochenski commented

As a further hint, it might also help to declare the class as a regular @Component instead of @Configuration. If you are not using cross-@Bean method calls within such a class, a simple stereotype does the job as well - and avoids CGLIB completely. We call these 'lite' configuration classes.
Thanks, I somehow got the wrong impression that @Bean would only work on a @Configuration

Finally, I wouldn't drop in a new Spring Framework version without regression testing either. I was just suspecting that you're in such a testing phase anyway since you upgraded to Java 7, and a minor Spring Framework upgrade would go along with that rather easily.
I understand what you mean, I'm just being super cautions. Jvm update is a big change -- don't want to complicate tracing other problems.

As for the documentation not mentioning that combination, well, there are plenty of feature combinations not mentioned and not officially supported. We're generally willing to support whatever people choose to use but I'm afraid we can't anticipate potential side effects for unexpected combinations.
Yes, but I'd say it's kind of a peculiar case that there are certain interfaces (and outside of spring home package), which the beans you register can't implement.
What I'm proposing is e.g. a note next to the JSR-330 annotation support table.
I'm not the only person who was trying to do this, e.g. https://stackoverflow.com/questions/4583768/how-do-i-configure-jsr-330-provider-and-inject-namedfoo-string-programm

[spring-projects-issues]

Juergen Hoeller commented

This looks like the same effect as in #14894, caused by return type differences in the factory method invocation. Since the Provider interface is generically typed, the compiler will create a bridge method a la "Object get()" next to the actual get() method that you declare, and the JVM exposes those methods at runtime in a potentially varying order... This may also explain why you're only seeing that effect for a specific configuration class - potentially the only one with a specific generic return type with a nested type variable?

As of the fix in #14894, we're ignoring return type differences for the purposes of our factory method invocation algorithm, so there's a strong chance that your scenario has been fixed there as well. Note that #14894 has been fixed in Spring Framework 3.2.2 (!), just one maintenance version ahead of what you're using... released in March 2013. I can't reproduce this against current Spring versions, in any case - so to get rid of the workarounds suggested above, please upgrade to a more recent Spring 3.2.x version.

Juergen