gnodet commented on code in PR #26148:
URL: https://github.com/apache/camel/pull/26148#discussion_r3952111313
##########
tooling/maven/camel-package-maven-plugin/src/main/java/org/apache/camel/maven/packaging/EndpointSchemaGeneratorMojo.java:
##########
@@ -423,7 +423,8 @@ private boolean addEndpointHeader(ComponentModel
componentModel, String scheme,
description = getHeaderFieldJavadoc(field);
}
header.setDescription(description);
- header.setKind("header");
+ String kind = metadata.kind();
+ header.setKind(kind.isEmpty() ? "header" : kind);
Review Comment:
⚠️ **New pattern — catalog consumers may not handle this correctly.**
This change allows `kind = "exchangeProperty"` to flow into the `headers`
section of the generated catalog JSON. No other component uses this pattern
today. Consumers that call `getEndpointHeaders()` iterate all entries and may
treat `CamelOpenAIAgenticTrace` as a settable message header rather than an
exchange property, regardless of the `kind` field — because the lookup contract
for exchange properties is a different API path.
Consider whether the right fix is:
1. Adding a dedicated `exchangeProperties` section to the component catalog
JSON (schema change, broader impact), or
2. Simply documenting `CamelOpenAIAgenticTrace` in the `.adoc` and omitting
it from the catalog `headers` section (exchange properties set internally don't
typically need catalog registration).
Option 2 avoids a schema change and aligns with how most internal exchange
properties are handled in Camel.
--
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]
