Agent dies with java.lang.NoClassDefFoundError: javassist/util/proxy/MethodHandler

[wbr...@neoguildsystems.com]

Trying to start the agent in the

org.zeroturnaround.exec.ProcessExecutor - Executing [C:\Program Files\Java\jdk-9.0.1\bin\java, -classpath, C:\Users\w\AppData\Local\Temp\13732@DESKTOP-RLC0TBQ\de.invesdwin.instrument.internal.DynamicInstrumentationLoadAgentMain.jar, de.invesdwin.instrument.internal.DynamicInstrumentationLoadAgentMain, 13732, C:\Users\w\AppData\Local\Temp\13732@DESKTOP-RLC0TBQ\de.invesdwin.instrument.internal.DynamicInstrumentationAgent.jar].

Using jdk 9.

It seems pretty clear to me that no where in the code is the javassist jar being added to the agent jar that is trying to attach to my process and you can that the process executor isnt adding it to the classpath.

Wanted to add it to the lib/ext directory... that's out with jdk 9.

Not sure if Im just ddoing something stup or not. Any ideas?

Thanks
Bill

[wbr...@neoguildsystems.com]

BTW: I fixed this trivially by adding

String classpath = loadAgentJar.getAbsolutePath();
List<String> items = Arrays.stream(System.getProperty("java.class.path").split(";")).filter(i -> i.contains("javassist")).collect(Collectors.toList());
if(items.size() == 1) {
    classpath += ";" + items.get(0);
}

To the list relevant part of the loadAgent method

[Edwin Stang]

Thanks for reporting this. I have made a commit to attach the parent process classpath to the agent classpath here: https://github.com/subes/invesdwin-instrument/commit/22a83ea19befee8061ad12b149e305fe64fe8091
This should be more robust for future changes. Can you try that the new snapshot version works? If so I will release version 1.0.1.

Best regards,
Edwin

[Edwin Stang]

Nevermind the previous commit, it neither worked with java 9 nor with spring-boot. Here a refined approach of bundling javassist classes into the agent jar: https://github.com/subes/invesdwin-instrument/commit/fd8a5120f5ff9a45639d09714f7c7b6402591925

Reading the classpath will not work when the instrumentation is launched from a nested classloader like it is done in spring-boot fat jars. In that case the system property for the classpath is misleading.

[wbr...@neoguildsystems.com]

Cool, thanks for the quick update. Ill try it.

I see you added a bunch of classpath scanning is the use of reflection and all the classes being loaded going to remove those found classes or scanned classes from potential loadtimeweavers since they'll be loaded before initialization? Not sure if it matters, just thinking about the side effects...

[Edwin Stang]

You are right, this defeats the purpose. I will compile a list of classes that needs to be managed manually for this. Or do you have a better idea?

[Edwin Stang]

I found a simpler and better manageable solution: https://github.com/olivergondza/maven-jdk-tools-wrapper/

With this we can drop the javassist dependency and use our own: de.invesdwin.instrument.internal.DummyAttachProvider

See the commit: https://github.com/subes/invesdwin-instrument/commit/7328e0161d4e7904bfeded8d68dc16365c48f5b5

[wbr...@neoguildsystems.com]

Getting rid of javassist definitely seems like the right way to go.

If you are taking requests, the configuration side could be more configurable. Not tied to spring except by default.

Maybe let you pass a method descriptor to the agent so that if you wanted to stash the instrumentation is an arbitrary spot rather than just for spring configurations.

[wbr...@neoguildsystems.com]

The best solution imo is one where the agent string parameters would be configured to setup a matcher that automatically finds the appropriate classes on which to set the Instrumentation.

If you want i can take a stab at it.

[Edwin Stang]

I have implemented a simpler solution: https://github.com/subes/invesdwin-instrument/commit/76938b11403e7e98a4f26053e6b2af88b503e68e

With DynamicInstrumentationReflections.getInstrumentation() you can access the instrumentation and further work with it after the instrumentation is done.

If you want to get rid of the spring dependencies, this would require a larger refactoring. Maybe allowing to set a delegate agent via ServiceLoader definition similar to how it is done with the IInstrumentationHook of invesdwin-context: https://github.com/subes/invesdwin-context#hooks

Though motivation is not too high to do that refactoring right now. :D

Best regards,
Edwin

[wbr...@neoguildsystems.com]

I am hoping to integrate with but not necessarily depend on spring.

Since the spring InstrumentationLoadTimeWeaver class isn't in the Agent jar, this will fail if spring isnt in the vm classpath correct?

[William Rusch]

nevermind i see the trick you did with the classloader

--
You received this message because you are subscribed to a topic in the Google Groups "invesdwin-platform" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/invesdwin-platform/kRx4JDbmfr0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to invesdwin-platform+unsub...@googlegroups.com.
To post to this group, send email to invesdwin-platform@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/invesdwin-platform/b101cbd6-56c5-4e43-8f98-3b9220a86089%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[subes]

I have now released version invesdwin-instrument-1.0.1 for java 9 and higher support. It includes the fix as discussed here.