Camel 21302

[ffang]

Description

Target

• [ ] I checked that the commit is targeting the correct branch (note that Camel 3 uses camel-3.x, whereas Camel 4 uses the main branch)

Tracking

• [ ] If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

• [ ] I checked that each commit in the pull request has a meaningful subject line and body.

• [ ] I have run mvn clean install -DskipTests locally from root folder and I have committed all auto-generated changes.

[github-actions[bot]]

:star2: Thank you for your contribution to the Apache Camel project! :star2:

:robot: CI automation will test this PR automatically.

:camel: Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run

• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot.

• You can label PRs using build-all, build-dependents, skip-tests and test-dependents to fine-tune the checks executed by this PR.

• Build and test logs are available in the Summary page. Only Apache Camel committers have access to the summary.

• :warning: Be careful when sharing logs. Review their contents before sharing them publicly.

[ffang]

This PR includes @johnpoth 's AsyncCxfTest, a proposal fix(and testcase to expose this issue without cxf endpoint involved) for CAMEL-21302, also revert commits introduced by CAMEL-21309, as if I read the camel-tracing code correctly, the problem is from camel-direct component but not camel-cxf.

Thanks for review!

Freeman

[johnpoth]

Great job @ffang ! Tested locally and everything seems to be working fine! I guess we might want to remove the AsyncCxfTest changes at some point since it turned out to be unrelated ?

[davsclaus]

the otel/tracing code is complex and even more those otel frameworks. its a bit pita that this fix needs to have code scattered in camel-direct / camel-tracing / camel-core that is complex to remember how is working together.

Hope that these otel frameworks becomes more friendly and dont have this hard thread local issue

[ffang]

Great job @ffang ! Tested locally and everything seems to be working fine! I guess we might want to remove the AsyncCxfTest changes at some point since it turned out to be unrelated ?

Thanks @johnpoth for the feedback!

I'd keep your AsyncCxfTest here if it's OK to have camel-cxf as test scope dependency in camel-opentelemetry.

Freeman

[ffang]

the otel/tracing code is complex and even more those otel frameworks. its a bit pita that this fix needs to have code scattered in camel-direct / camel-tracing / camel-core that is complex to remember how is working together.

Hope that these otel frameworks becomes more friendly and dont have this hard thread local issue

Totally agree! Especially when async gets involved!

[johnpoth]

I did a small PoC to rewrite [1] camel-opentelemetry by removing the thread local stuff and I also removed the dependency on camel-tracing. The problem is that a lot of other libraries rely on the thread local context [2] to be set. To mitigate that, we could set and unset the threadlocal in a InterceptStrategy so that libraries would be able to retrieve it. I do think we can leave it as it is now and maybe come back to this idea if things get too complicated.

[1] https://github.com/johnpoth/camel/tree/opentelemetry-rewrite/components/camel-opentelemetry [2] https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/javaagent-extension-api/src/main/java/io/opentelemetry/javaagent/bootstrap/Java8BytecodeBridge.java#L22 [2] https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation