CAMEL-23312: Add SpanKind support to OpenTelemetry2 component

[JiriOndrusek]

fixes https://issues.apache.org/jira/browse/CAMEL-23312
superseeds #22577

• Adds SpanKind support to the OpenTelemetry2 component to enable proper distributed tracing
  semantics
• Implements SpanKind determination through the SpanDecorator API with HTTP components using
  CLIENT/SERVER and messaging components using PRODUCER/CONSUMER
• Includes comprehensive test coverage with mock HTTP and Kafka components to verify SpanKind
  behavior and decorator property inheritance

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.

[JiriOndrusek]

@squakez here is the refactored PR (much simpler and cleaner), I force pushed this change to my branch, unfortunately this blocks reopening of #22610 (I didn't know about such limitation). Therefore this is the new PR.

[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

All tested modules (8 modules)

• Camel :: JBang :: MCP
• Camel :: JBang :: Plugin :: Route Parser
• Camel :: JBang :: Plugin :: Validate
• Camel :: Launcher :: Container
• Camel :: Observability Services
• Camel :: Opentelemetry 2
• Camel :: YAML DSL :: Validator
• Camel :: YAML DSL :: Validator Maven Plugin

---

⚙️ View full build and test results

[squakez]

Hello, thanks again for the work but it appears to be quite far from what I was proposing.

The change I'm advocating for are quite simple and compliant with the actual design. What I think you need to do is to change the implementation of the dedicated beforeTracingEvent(Span span, Exchange exchange, Endpoint endpoint) for those decorators (messaging and http based) which you want to add a kind. For example:

camel/components/camel-telemetry/src/main/java/org/apache/camel/telemetry/decorators/AbstractHttpSpanDecorator.java

Lines 67 to 75 in 061ae7d

	public void beforeTracingEvent(Span span, Exchange exchange, Endpoint endpoint) {
	super.beforeTracingEvent(span, exchange, endpoint);
	String httpUrl = getHttpURL(exchange, endpoint);
	if (httpUrl != null) {
	span.setTag(TagConstants.HTTP_URL, httpUrl);
	}
	span.setTag(TagConstants.HTTP_METHOD, getHttpMethod(exchange, endpoint));
	}

Here you need to add a tag to the existing Span object, i.e. span.setTag("kind", "my-kind"). The method gives you everything you need to perform the action. If you need the Op type, you can extend both the before and after tracing with such an object. In this way it will be available for any type evaluation inside that method.

Hope it helps.

[squakez]

Alternatively we could even think to expose the "kind" in the Span (ie, span.kind()), just for the sake to avoid adding the Op in the decorator methods. In this way all you need is self contained and indeed you can have as much as Kind types as you need in the SpanAdapter which is implemented at a concrete component level. Yeah, I think this is the best way to handle to minimize the impact and be compliant with the design.

[JiriOndrusek]

Hi @squakez,

I've tried to follow your hints.
1 - I agree with avoiding Op in decorators
2 - I added span.kind() into Span and started from it.
Unfortunately the io.opentelemetry.api.trace.Span needs to know its spanKind before starting. I had to deffer the start of the span into the makeCurrent method to be able to detect the spanKind. I put the spanKind detection into OpenTelemetrySpanAdapter and kept it completely self contained. (I used other tags for it) So I actually did not need the span.kind() anymore. What do you think? from my PoV the change is quite small and isolated to opentelemetry2. No API is changed. Test suite is the same as in previous attempts.

[davsclaus]

should these map/list be concurrent variants in case multi threads calls at the same time

[JiriOndrusek]

I discussed the changes with @squakez and I'll open the new PR which does not need all this code for defferring span creation

[JiriOndrusek]

superseded by #22653