Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-issuemaster opened this issue Nov 30, 2017 · 2 comments

Comments

@spring-issuemaster
Copy link
Collaborator

commented Nov 30, 2017

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 1, 2017

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 7, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.