Support load time weaving in Liberty without the agent [SPR-16248]

[spring-projects-issues]

Alasdair Nottingham opened SPR-16248 and commented

There is a load time weaver for WebSphere traditional so there is no need to specify the javaagent, but there isn't for the more modern WebSphere/Open Liberty which makes using Spring AOT on Liberty harder. The Liberty application classloader has the following method:

public boolean addTransformer(final ClassFileTransformer cft);

that can be used to register a java.lang.instrument.ClassFileTransformer. The method has a comment that says it is there for Spring, but it doesn't appear that it'll ever be called.

The current detection logic uses com.ibm. as an indicator on the class name for WebSphere and that isn't correct on Liberty.

The Liberty classloader code is here: https://github.com/OpenLiberty/open-liberty/blob/integration/dev/com.ibm.ws.classloading/src/com/ibm/ws/classloading/internal/AppClassLoader.java

---

Referenced from: commits d187cbc

[spring-projects-issues]

Juergen Hoeller commented

Spring's DefaultContextLoadTimeWeaver chooses WebSphereLoadTimeWeaver for any original class loader starting with com.ibm.... which should lead to an IllegalStateException being logged on Liberty, with the fallback ReflectiveLoadTimeWeaver kicking in. Since the latter is the convention-based adapter that Liberty is taking into account, it should actually work already, just with a misleading info message being logged. Or am I missing something here?

To be clear, this is worth refining in any case: We could for example check for com.ibm.ws.classloader., ignoring Liberty's com.ibm.ws.classloading. to begin with and therefore choosing ReflectiveLoadTimeWeaver in such a scenario right away.

[spring-projects-issues]

Juergen Hoeller commented

I've narrowed our check to com.ibm.ws.classloader for Spring Framework 5.0.3, not trying to apply the traditional WebSphereLoadTimeWeaver to Liberty anymore. Correspondingly, I've also tightened our JBoss check to org.jboss.modules, not accidentally covering other JBoss ClassLoader implementations as well. Also, we're catching Exception from server-specific initialization now instead of just IllegalStateException, providing a lenient fallback for any unexpected mismatches that remain.

For 4.3.14, I'll broaden the exception catch to Exception as well, while leaving the other checks in place as-is. You should be seeing an info log entry then (not having found the traditional WAS CompoundClassLoader) but it should still work on Liberty out of the box.