Load time weaving does not work for classes in external references (i.e. JARs packaged in EAR's APP-INF/lib folder) [SPR-6176]

[spring-projects-issues]

Klaus Kreuzwieser opened SPR-6176 and commented

We have annotated classes with @Configurable and want that all @Autowired fields are injected. This works fine if all classes annotated with @Configurable are located in the WEB-INF/lib folder (for a web application), but does not work when the classes are in a JAR modules in APP-INF/lib folder.

Consider the following scenario: An EAR consists of several application modules (i.e. WAR files) which have roughly the same dependencies. To prevent the packaging of duplicate JAR files in all WARs, we create "skinny WAR files" (see http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html). The WAR dependecies are packaged in a library folder (i.e. APP-INF/lib) and are referenced via the Class-Path setting in the WAR's META-INF/MANIFEST.MF. All classes annotated with @Configurable which are located in the external referenced JAR files are not woven at load time. All classes annotated with @Configurable which are packaged into the web application itself (either under WEB-INF/classes or WEB-INF/lib) are correctly woven at load time.

We are using WebLogic 10.3 as J2EE container, but I have found a similar problem (http://forum.springsource.org/showthread.php?t=50778) concerning JBoss - so this problem seems to be container unrelated.

I'l attach 2 zip files for reproduction: ltw-fat works fine, ltw-skinny throws a NullPointerException because the Configurable Conf1 is not woven.

---

Affects: 2.5.6

Reference URL: http://forum.springsource.org/showthread.php?t=50778

Attachments:

• ltw-fat.zip (14.76 kB)
• ltw-skinny.zip (15.20 kB)

[spring-projects-issues]

Klaus Kreuzwieser commented

ltw-fat creates WAR files with all dependencies under WEB-INF/lib - @Configurable works ltw-skinny creates skinny WAR files - @Configurable does not work

[spring-projects-issues]

Costin Leau commented

Hi Klaus,

To quote the J2EE spec

An EAR file is used to package one or more J2EE modules into a single module so that they can have aligned classloading and deployment into a server.

The LTW integration relies on the behaviour of the application server class loader. An EAR with multiple WARs is implemented as one classloader (the EAR) with several children (one classloader per WAR) to provide isolation. By enabling an LTW inside an WAR, one instructs Spring to provide instrumentation to its containing classloader (i.e. the WAR classloader), which again, is isolated from the rest. I don't know how the Class-Path setting is implemented in WebLogic but since the classes are loaded from the EAR and not the WAR, it's expected that they are not instrumented. Consider the case where an EAR contains two WARs, one that is instrumented and one that isn't. By applying the instrumentation EAR-wide, the EAR shared classes would be instrumented as well which means the second WAR would be instrumented even though that's not the case.

The problem here is that Spring is scoped to a module (the WAR) which is part of a bigger picture, the EAR of which the WAR (and thus Spring) should be unaware. A solution would be to make the application (and Spring) EAR-aware/EAR wide but since there are no lifecycle hooks for the entire EAR (the big module) one is limited to sub modules.

[spring-projects-issues]

Juergen Hoeller commented

As Costin said, there is unfortunately nothing we can do about this. Load-time weaving only works for specific deployment units such as WARs, and even there it is considered an advanced feature that won't work in all runtime environments.

As an alternative, consider using compile-time weaving using AspectJ's compiler against all affected classes. This will be faster on startup and will work with any deployment layout.

Juergen

[spring-projects-issues]

Jeff Mitchell commented

Hi, Im coming in on the tail end of this after suffering similar issues.

One question I have - is this just the way things are or does Spring 3.x go some way to alleviate this ?