allthingssecurity opened a new pull request, #27587: URL: https://github.com/apache/camel/pull/27587
# Description [CAMEL-25360](https://issues.apache.org/jira/browse/CAMEL-25360) Follow-up that @davsclaus asked for in the review of #27342 (CAMEL-25301): the `application-cloudevents+json` data type nested anything that looks like JSON regardless of `datacontenttype` (a `text/plain` body `[1,2]` became an array), wrote JSON scalars under `application/json` as strings, and never used `data_base64` for binary bodies. This change writes the data as the CloudEvents JSON format (section 3.1) describes, using the `datacontenttype` of the event (the `CamelCloudEventDataContentType` header, else `Content-Type`, else `application/json`): - JSON media type (subtype `json` or suffix `+json`, parameters and case ignored): a body that is a JSON value is nested, now including a string, number, `true`, `false` or `null`. A body that is not valid JSON is a string, as the scan from #27342 already does. Without a content type this is the default, so default routes behave as before except for scalar bodies (`42` now gives `"data":42`). This keeps the reason for scanning the body that we discussed in #27342: the default `application/json` does not make a log line like `[INFO] ...` nested; - any other content type: the body is a string, also when it is a JSON object or array. A nested value under a content type that is not JSON is rejected by CloudEvents readers; the CloudEvents Java SDK fails with "Because content type is not a json, only a string is accepted as data"; - a `byte[]` body that is not valid text in the charset of the exchange (UTF-8 by default), whatever the content type: `data_base64`, instead of being decoded with the invalid bytes replaced. A `byte[]` body that is valid text is written as text as before (valid UTF-8 written as a JSON string gives a reader the same bytes back), and other bodies (an `InputStream`, a stream cache) are read as text as before. All three change the output of existing routes, so there is a new `=== camel-cloudevents - ... (Breaking change)` section in the 4.23 upgrade guide (there was none), kept short: the three changes and how to keep a JSON body nested. One impact needs a look: several component CloudEvent data types declare a content type that is not JSON whatever the body is. `aws2-s3`, `aws2-kinesis`, `google-pubsub`, `azure-eventhubs`, `azure-storage-blob` and others declare `application/octet-stream`, and `aws-cloudtrail`, `azure-storage-queue` and `azure-cosmosdb` declare `text/plain`. Followed by `application-cloudevents+json`, a JSON body of such a message (a CloudTrail event always is one) is now a JSON string instead of nested. That follows the content type those data types declare, and is what CloudEvents readers accept; the upgrade guide says how to keep the JSON nested (`CamelCloudEventDataContentType=application/json`). I first wrote every `byte[]` body of these content types as `data_bas e64`, but that would have turned all text and JSON records of Kinesis, Pub/Sub, Event Hubs and S3 into Base64, so only bytes that are not valid text are Base64 now. No Kamelet uses `application-cloudevents+json`. Tests (`CloudEventJsonDataTypeTransformerTest`): - `shouldNotNestJsonDataOfANonJsonContentType`, `shouldUseTheDataContentTypeOfTheEvent`, `shouldNestJsonScalarsOfAJsonContentType`, `shouldWriteBinaryDataAsBase64`, `shouldWriteBytesThatAreNotValidTextAsBase64WhateverTheContentType` and `shouldWriteBytesThatAreValidTextAsStringWhenTheContentTypeIsBinary` fail without the change; - `shouldNestJsonOfAnyJsonContentType` (`+json`, parameters, case), `shouldKeepTextOfAJsonContentTypeThatIsNotJsonAsString` (text that is not a JSON value), `shouldWriteBytesOfTextOrJsonContentTypesAsData` and `shouldDecodeBytesInTheCharsetOfTheExchange` cover the new content-type parsing, the scalar scan and the byte decoding on inputs whose output does not change, so they also pass on main. The existing tests are unchanged. camel-cloudevents module with the change: 24 tests, 0 failures. # Target - [x] I checked that the commit is targeting the correct branch (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). # Apache Camel coding standards and style - [x] 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. (I built and tested the affected module, including the formatter and import-sort plugins. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commits carry a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
