christophd opened a new pull request, #10493: URL: https://github.com/apache/camel/pull/10493
# Description <!-- - Write a pull request description that is detailed enough to understand what the pull request does, how, and why. --> This PR enhances the mechanism of input/output DataType and Transformer in order to support multiple data types on components as described in https://issues.apache.org/jira/browse/CAMEL-18698 The existing Transformer and DataType support is enhanced with - Add data type to transform EIP resulting in a transformation from given type to target type using a matching transformer implementation - Enhance data type transformer resolving mechanism to support: - Lazy loading of transformer implementations via resource path factory finder - Add annotation based transformer loader (adds possibility to load transformer implementations with classpath scan) - Add possibility to configure preloading of default Camel transformer implementations - Add default Camel transformer implementations for String and byte[] - Add CloudEvents transformer implementation to transform any Camel Exchange into CloudEvent using Http or Json binding - Add AWS S3 CloudEvents transformer implementation to transform getObject response into proper CloudEvent The idea is to add Transformer implementations to Camel components that match data type information given on the route as an input/output type. Based on that data type contract the Camel internal advice will automatically resolve matching transformer implementations and apply its data type transformation logic as part of the route. Transformer implementations may be preloaded via Camel context configuration or lazy loaded via factory finder resource path lookup. Users may also explicitly use a transform EIP as part of the route and provide a target data type as an outcome of the transformation. Based on that data type information the same Transformer resolving mechanism may find a matching transformer implementation and apply its logic. This enhances the declarative contract based data type transformation in routes and suits best for usage in KameletBindings where the user declaratively specifies input/output data types as part of a binding. Each Kamelet may expose supported supported data type specifications for input and output and leverage the provided transformer implementations in Camel components. As an example this PR adds transformer implementations for CloudEvents (Http and Json binding) so users may transform any Exchange data into a proper CloudEvent by just specifying the respective data type (`http:application/cloudevents` or `application/cloudevents+json`). The AWS S3 component also adds a new transformer implementation (`aws2-s3:application-cloudevents`) to create a proper CloudEvent with attributes filled from the data coming from the AWS S3 getObject response. This way the user is able to use the same AWS S3 component to properly create CloudEvent data type format. Example: ```yaml apiVersion: camel.apache.org/v1alpha1 kind: KameletBinding metadata: name: aws-s3-cloudevents-source spec: source: ref: kind: Kamelet apiVersion: camel.apache.org/v1 name: aws2-s3-source dataTypes: out: format: aws2-s3:application/cloudevents properties: [...] sink: ref: kind: Kamelet apiVersion: camel.apache.org/v1 name: http-sink dataTypes: in: format: application/cloudevents+json properties: url: http:localhost:8080 ``` The binding uses the component specific `aws2-s3:application/cloudevents` data type in order to apply the CloudEvent transformation provided in the aws2-s3 component (sets CloudEvent attributes with data from the getObject response). Then in the sink the `application/cloudevents+json` input data type is used to transform the S3 event into a proper CloudEvent Json binding. Successor PR for #8694 Closes #8694 # Target - [x] I checked that the commit is targeting the correct branch (note that Camel 3 uses `camel-3.x`, whereas Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). https://issues.apache.org/jira/browse/CAMEL-18698 <!-- # *Note*: trivial changes like, typos, minor documentation fixes and other small items do not require a JIRA issue. In this case your pull request should address just this issue, without pulling in other changes. --> # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. <!-- If you're unsure, you can format the pull request title like `[CAMEL-XXX] Fixes bug in camel-file component`, where you replace `CAMEL-XXX` with the appropriate JIRA issue. --> - [x] I have run `mvn clean install -DskipTests` locally and I have committed all auto-generated changes <!-- You can run the aforementioned command in your module so that the build auto-formats your code. This will also be verified as part of the checks and your PR may be rejected if if there are uncommited changes after running `mvn clean install -DskipTests`. You can learn more about the contribution guidelines at https://github.com/apache/camel/blob/main/CONTRIBUTING.md --> -- 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: commits-unsubscr...@camel.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
