This is an automated email from the ASF dual-hosted git repository.
squakez pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/main by this push:
new 47d7f9090a8d chore(proposals): provide latest design changes
47d7f9090a8d is described below
commit 47d7f9090a8dd06bc26b7d4bad959c8cc6fcb62a
Author: Pasquale Congiusti <[email protected]>
AuthorDate: Fri May 8 09:13:58 2026 +0200
chore(proposals): provide latest design changes
Ref CAMEL-23432
---
proposals/tracing.adoc | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/proposals/tracing.adoc b/proposals/tracing.adoc
index 9d91978df7e2..2dad31f57653 100644
--- a/proposals/tracing.adoc
+++ b/proposals/tracing.adoc
@@ -9,7 +9,7 @@ approvers:
- "@zbendhiba"
- "@davsclaus"
creation-date: 2025-01-08
-last-updated: 2026-05-04
+last-updated: 2026-05-07
status: implemented
see-also: []
replaces: []
@@ -167,3 +167,9 @@ As described in
https://issues.apache.org/jira/browse/CAMEL-23380 any version be
In order to prevent this problem we need to rethink the implementation details
of `camel-opentelemetry2` and remove the explicit `Scope` management that, when
asynchronous, was opening the `Scope` in a thread and closing in another (what
we had called "dirty" context). We are now removing this explicit management
and moving this part exclusively in the custom Camel `Processors`. Here Camel
will take care to open the Opentelemetry scope and close it within the same
thread.
What it means is that, from now on we get rid of the leak but the final user
or any third party dependency can only access the Opentelemetry context within
the boundary of a Processor execution.
+
+=== Distinguish custom Processors from core Processors (2026-05-07)
+
+The custom processors must be distinguished from core processors in order to
let the user disable span generation only for custom processors. This is an
**important design constraint** required to ensure that the core processors
spans are always generated during an execution. With this constraint we ensure
that any third party instrumentation span (which generally happens at core
Processor level) is correctly nested.
+
+Disabling this feature is possible and could work for simple tracing. However
it is not recommended and the user should always fine tune the exclusions of
processors explicitly in case he wants to reduce the number of generated spans.