Regression: Spring on WildFly causing ClassNotFoundException in ASM when deployed outside of EAR [SPR-13695]

[spring-projects-issues]

cns-web opened SPR-13695 and commented

Hi, the problem affects my deployment since 4.2.3 (in 4.2.2 everything worked fine)..

See the reference url for the description with stack:

Short summary

• EAR on Wildfly which has dependency to spring module
• Spring module is deployed within the wildfly modules folder (not bundled with the deployment ear!)

Reason for the CNFE:

• getClass().getClassLoader() called in context of spring-jar for classes which are in the deployment EAR. ->> Different classloader

If you need any additional info i will provide.

---

Affects: 4.2.3

Reference URL: 8c4b8d2#commitcomment-14416143

Issue Links:

• Unable to intercept methods with mixed enum types as varargs [SPR-13328] #17913 Unable to intercept methods with mixed enum types as varargs

Referenced from: commits 20a286b

[spring-projects-issues]

Juergen Hoeller commented

This is actually a code path in ASM - which we're simply repackaging in its original form there, with very minor patches only - that seems to get triggered now that we handle varargs differently during method interception (see #17913 for the original purpose there). Since we do effectively have our own fork of ASM within our framework, we should be able to change that code to use the application's ClassLoader instead.

However, the actual weirdness is in ASM itself: A library that is designed to process class files without loading the classes through a ClassLoader... obtains the ClassLoader that it has been loaded with itself and tries to identify a common superclass of two application classes that it is currently trying to process? And in the end, it just returns plain type names again, so it was only using those Class references temporarily...

Juergen

[spring-projects-issues]

Juergen Hoeller commented

I've addressed this through consistent exposure of the current application ClassLoader as the thread context class loader during class generation attempts, for our ASM ClassWriter variant to pick it up through a Thread.currentThread().getContextClassLoader() check. It seems we should always have done this but there simply wasn't a concrete case for it before, with that ClassLoader-using ASM code apparently never getting invoked before (or maybe everybody who ran into that code had the framework co-located with the application classes).

I hope that this actually fixes your problem. Please give the upcoming 4.2.4.BUILD-SNAPSHOT (in about an hour) a try on your WildFly deployment arrangement and let me know how it goes...

Juergen

[spring-projects-issues]

cns-web commented

Hi i tried the snapshot today ( https://repo.spring.io/snapshot/org/springframework/spring/4.2.4.BUILD-SNAPSHOT/spring-framework-4.2.4.BUILD-SNAPSHOT-dist.zip -> 01:14 ) and it seems to be working again :) Thanks for addressing this so quickly

[spring-projects-issues]

Alvise Vitturi commented

It works, i tested the snapshot 02/Dec/15.