This is an automated email from the ASF dual-hosted git repository. davsclaus pushed a commit to branch code-massel-CAMEL-23352 in repository https://gitbox.apache.org/repos/asf/camel.git
commit 82b0586c8b0aa72a182b1679d44204568d2a8f8e Author: Pasquale Congiusti <[email protected]> AuthorDate: Thu May 7 08:46:47 2026 +0200 chore(doc): explain core processors changes --- .../modules/ROOT/pages/camel-4x-upgrade-guide-4_21.adoc | 13 +++++++++++-- proposals/tracing.adoc | 8 +++++++- 2 files changed, 18 insertions(+), 3 deletions(-) diff --git a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_21.adoc b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_21.adoc index ced0afa3677c..8e70f77d4738 100644 --- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_21.adoc +++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_21.adoc @@ -218,7 +218,17 @@ Camel Grape was deprecated with Camel 4.0. The component is now removed. === camel-telemetry -If you have custom telemetry implementations, the following interfaces have changed: +In order to prevent some potential span leakage in `camel-opentelemetry2` (see notes below) we had to perform some changes and introduce the following parameter: + +``` +|`disableCoreProcessors`| false | Disable any inner core processors (any core DSL processor provided in the route, for example `bean`, `log`, ...). +``` + +This is required in order to distinguish the older `traceProcessors` parameter which now accounts **exclusively** for custom processors. Keeping the default parameter (`false`) could increase the number of spans generated, though, this is required to guarantee consistency and memory sealing. If you need to reduce the number of spans for any reason you can explicitly provide exclusion configuration. + +NOTE: turn `disableCoreProcessors` to `true` and `traceProcessors` to `false` to skip entirely all processors. However it is not recommended to disable core processors in order to avoid the generation of third party dependencies orphaned spans. + +In this version we have also changed certain interfaces, so, if you have custom telemetry implementations, you may need to adjust to them: ==== `org.apache.camel.telemetry.SpanLifecycleManager` @@ -271,4 +281,3 @@ The component camel-digitalocean is deprecated. The java library used has been u === Deprecation of camel-irc The component camel-irc is deprecated. The library used had no stable release since 2007. There is no Java library very active for this protocol. - 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.
