Instrumentation broken with OpenTracing on classpath about dd-trace-java HOT 4 CLOSED

The root cause is classpath related. The loader ParallelWebappClassLoader has a delegate: false property. What this means is that spring boot's classloader will load OT without delegating to the parent (bootstrap) loader. This will actually cause two different sets of OpenTracing classes to appear at runtime. One will be the OT classes used by Datadog, and the other the OT classes loaded by spring-boot.

The Datadog instrumentation notices this setup and backs its instrumentation off because injecting instrumentation in that scenario won't have the desired effect.

I realize this isn't a good "out of the box" experience. We're working on a long-term fix for these type of classloading scenarios.

In the meantime either one of these workarounds can be used:

• Configure the web classloaders with delegate=true: https://qiita.com/tkprof/items/b92d3a245045480afd26
• Put the OpenTracing classes on the system classpath instead of the web classpath

from dd-trace-java.

Thanks for the information! Since this is a traditional Spring app deployed to Tomcat as a WAR file it was easy to just add <Loader delegate="true"/> to the Tomcat context.xml. This has fixed the problem.

I'll leave this issue open to because the out-of-box experience could indeed use some improvement, but feel free to close it if this is already tracked somewhere else.

from dd-trace-java.

It's fine to leave this open. We'll track this and close it out when the fix lands. Thanks for confirming the workaround!

from dd-trace-java.

I think this is solved in 0.25.0+ with #741. Closing. Please reopen if still a problem.

from dd-trace-java.