[
https://issues.apache.org/jira/browse/CAMEL-24803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18120837#comment-18120837
]
Urmila Unni commented on CAMEL-24803:
-------------------------------------
Hi, I'd like to pick this up.
My plan is to add the CloudEvent header names with @Metadata to the existing
KnativeConstants class, point KnativeEndpoint to it via headersClass, and
regenerate the component JSON and catalog. Please let me know if you'd prefer a
different approach
> camel-knative - declare the CloudEvent message headers in the component
> metadata (headersClass), so the catalog, the docs and the validator know them
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24803
> URL: https://issues.apache.org/jira/browse/CAMEL-24803
> Project: Camel
> Issue Type: Improvement
> Components: camel-catalog, camel-knative
> Reporter: Claus Ibsen
> Priority: Major
>
> camel-knative sets and reads the CloudEvent headers of
> {{org.apache.camel.cloudevents.CloudEvent}} in camel-api
> ({{CamelCloudEventID}}, {{CamelCloudEventSource}}, {{CamelCloudEventType}},
> {{CamelCloudEventVersion}}, {{CamelCloudEventTime}},
> {{CamelCloudEventDataContentType}}, {{CamelCloudEventSubject}}, ...): the
> consumer puts them on every incoming event, the producer reads them to build
> the outgoing one, and the documentation tells the user to set
> {{CamelCloudEventType}} or {{CamelCloudEventID}} to customize the event. But
> {{KnativeEndpoint}} has no {{headersClass}} on its {{@UriEndpoint}}, so the
> component JSON in the catalog has no headers section at all.
> Consequences:
> * the headers table of the knative documentation page is empty;
> * {{camel validate yaml}} and the camel_validate_source tool reject a route
> that reads one of them, e.g. {{$\{header.CamelCloudEventType\}}} in a log
> message, with "header CamelCloudEventType is not set by knative", so the
> documentation cannot show them in a validated example (found while adding
> route examples to the knative page in CAMEL-24720);
> * an AI agent asking the catalog for the headers of knative gets none.
> Proposed: a {{KnativeConstants}} class that declares the CloudEvent header
> names with {{@Metadata}} (description, label consumer/producer, javaType),
> referenced by {{headersClass}} on {{KnativeEndpoint}}, then regenerate the
> component JSON and the catalog.
> Wider: about twenty modules set the same CloudEvent headers when a
> CloudEvents data type transformer is applied (aws2-s3, aws2-sqs,
> aws2-kinesis, aws2-ddb, aws-cloudtrail, azure-servicebus, azure-eventhubs,
> azure-storage-blob/queue/datalake, azure-files, azure-cosmosdb,
> google-pubsub, google-storage, google-calendar, google-mail, google-sheets,
> slack, camel-cloudevents), and no component JSON in the catalog mentions a
> {{CamelCloudEvent}} header. Once knative is done, decide whether to append
> the same constants to each component's constants class, or to let the plugin
> pick them up once from a shared class (the {{CloudEvent}} interface in
> camel-api annotated with {{@Metadata}} and referenced by each
> {{headersClass}}, if the package plugin accepts a class from another module
> and more than one class per endpoint; else a constants class in
> camel-cloudevents).
> _Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
