gnodet commented on PR #1730: URL: https://github.com/apache/camel-spring-boot/pull/1730#issuecomment-4125098857
@squakez Thanks for the feedback. After reading the [design doc](https://github.com/apache/camel/blob/main/proposals/tracing.adoc) more carefully, I agree the [core camel PR #22190](https://github.com/apache/camel/pull/22190) was wrong — wrapping all Camel-internal thread pools with `Context.taskWrapping()` contradicts the Exchange-based storage design. That one has been reverted in https://github.com/apache/camel/pull/22254. For this Spring Boot starter PR, the question is more nuanced. The `create()` method in `OpenTelemetrySpanLifecycleManager` does fall back to `Context.current()` when there's no Camel parent span and no `traceparent` header — this is the case where an OTel Java agent instruments the HTTP server and sets context via ThreadLocal, but Spring Boot's `ThreadPoolTaskExecutor` hands off to a different thread before Camel's `create()` runs, losing that ThreadLocal context. If `camel-opentelemetry2` should rely **exclusively** on W3C traceparent header-based propagation (as the design doc implies), then this `TaskDecorator` is unnecessary — the agent/upstream system should pass headers. But if the ThreadLocal fallback in `create()` is intentional and should work, then the Spring Boot starter is the right place to ensure Spring's thread pool preserves it (not the core component). So the real question is: should we remove the `Context.current()` fallback from `create()` and rely only on header extraction? Or is the fallback intentional for cases like Java agent instrumentation? Happy to close this PR if the answer is header-only. _Claude Code on behalf of Guillaume Nodet_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
