Problem with Context propagation with Apache Camel auto-instrumentation when using camel-blueprint (or Karaf)

When running Apache Camel with camel-blueprint in something like Apache Karaf, there is an issue with context propagation. This leads to an extra span being created on the first request that is never ended and thus not exported, and which will become the parent span for not just this request, but all subsequent requests. Leading to one trace that can last tens of minutes and contains (orphaned) spans from many requests.

The problem is https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/2f0d2320572b9e8da07834cf99898bad9c7666b0/instrumentation/camel-2.20/javaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/apachecamel/ActiveContextManager.java#L53

The ClassLoader for ContextWithScope when the property is set is the camel-blueprint one: org.eclipse.osgi.internal.loader.EquinoxClassLoader@1901b0b7[org.apache.camel.camel-blueprint:2.24.2(id=230)], but when the property is retrieved later, that ClassLoader is the camel-core one: org.eclipse.osgi.internal.loader.EquinoxClassLoader@6cad635c[org.apache.camel.camel-core:2.24.2(id=49)]

That means that the exchange.getProperty(ACTIVE_CONTEXT_PROPERTY, ContextWithScope.class); invocation returns null, because even though the class is ContextWithScope in both cases, they are loaded by different ClassLoaders, and thus different.

The (one?) fix is to use the regular getProperty method to get an Object back that we cast to the ContextWithScope that is currently loaded.
I have this fix ready in my fork: https://github.com/open-telemetry/opentelemetry-java-instrumentation/compare/main...evanderkoogh:opentelemetry-java-instrumentation:talendESB-context-fix

Is it ok to open up a PR with this change? Or is there another preferred way of solving this?

Start in instrumentation/camel-2.20/javaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/apachecamel/ActiveContextManager.java at the ACTIVE_CONTEXT_PROPERTY lookup around line 53. Compare the typed property access with the reported class-loader mismatch and verify that the active context is retrieved correctly, so the first request does not leave an orphaned span or parent later requests.