chore(components): specify custom span nesting in opentelemetry

[squakez]

As we have moved the scope only for Processors, any call to the endpoint, which generates an event is not providing the scope. This is needed by custom span to nest the execution under the specific processor. Added some test and documentation to clarify this architecture constraint.

Description

Target

• I checked that the commit is targeting the correct branch (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.

[squakez]

@davsclaus @oscerd I need you to please have a look at this one. Please, advise if the documentation explaining the design constraint is wrong or should be reworded.

Also, I wonder if this analysis is overlooking something. I understand that when we configure, for example, a bean to be called as an endpoint, then, the execution "converts" it as an event. Is there any possibility to have it as a regular processor and make the otel component to intercept it in the "InterceptStrategy" instead?

Thanks!

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 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 although they are normally detected and executed by CI.
• You can label PRs using 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.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[github-actions]

🧪 CI tested the following changed modules:

• components/camel-opentelemetry2
• components/camel-telemetry

All tested modules (12 modules)

• Camel :: Common Telemetry
• Camel :: JBang :: MCP
• Camel :: JBang :: Plugin :: Route Parser
• Camel :: JBang :: Plugin :: TUI
• Camel :: JBang :: Plugin :: Validate
• Camel :: Launcher :: Container
• Camel :: Micrometer :: Observability 2
• Camel :: Observability Services
• Camel :: Opentelemetry 2
• Camel :: Telemetry :: Dev
• Camel :: YAML DSL :: Validator
• Camel :: YAML DSL :: Validator Maven Plugin

---

⚙️ View full build and test results

[oscerd]

It looks ok to me and it doesn't need to be reworded.

[gnodet]

Thanks for documenting this architectural constraint, @squakez — this is a genuinely useful addition that will save users from confusing debugging sessions when custom spans don't nest where expected.

A couple of items to address:

Required:

1. Remove System.out.println debug output in the otel2 test
2. Add missing beanTo.hasEnded() assertion in the otel2 test

Suggestions (non-blocking):
3. The telemetry test route has an extra .process(...) step not present in the otel2 test — consider aligning for easier cross-module comparison
4. The two tests assert different parent hierarchies for beanMethod — a clarifying comment in the telemetry test would help future readers

See inline comments for details.

Note: this is a project-conventions review and does not replace specialized tools like CodeRabbit, Sourcery, or SonarCloud.

Claude Code on behalf of Guillaume Nodet

[gnodet]

All feedback addressed — thanks for the quick turnaround, @squakez!

• System.out.println removed ✓
• Missing beanTo.hasEnded() assertion added ✓
• Routes aligned across modules ✓

LGTM.

Claude Code on behalf of Guillaume Nodet