[jira] [Resolved] (CAMEL-25360) camel-cloudevents - application-cloudevents+json ignores the datacontenttype when it writes the data: JSON of a text/plain body is nested, JSON scalars are strings, bytes that are not valid text are lost

["Claus Ibsen (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-25360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen resolved CAMEL-25360.
---------------------------------
    Resolution: Fixed

> camel-cloudevents - application-cloudevents+json ignores the datacontenttype when it writes the data: JSON of a text/plain body is nested, JSON scalars are strings, bytes that are not valid text are lost
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-25360
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25360
>             Project: Camel
>          Issue Type: Bug
>            Reporter: shashank
>            Assignee: shashank
>            Priority: Minor
>             Fix For: 4.23.0
>
>
> The {{application-cloudevents+json}} data type ({{CloudEventJsonDataTypeTransformer}}) decides how to write the body as the {{data}} of the event from the body alone: a body that is a JSON object or array is nested, anything else is a JSON string. The CloudEvents JSON format (section 3.1) decides by the {{datacontenttype}}: data whose content type is JSON ({{*/json}}, {{*/*+json}}, and {{application/json}} when it is absent) is a JSON value, other data is a string, and binary data is written Base64 encoded as {{data_base64}}. So:
> * a {{text/plain}} (or {{application/octet-stream}}) body {{[1,2]}} is written as {{"data":[1,2]}} instead of {{"data":"[1,2]"}}. CloudEvents readers reject such an event: the CloudEvents Java SDK ({{CloudEventDeserializer}}) fails with "Because content type is not a json, only a string is accepted as data";
> * under {{application/json}} (also the default), a body {{42}}, {{true}}, {{null}} or {{"text"}} is written as a string ({{"data":"42"}}, {{"data":"\"text\""}}), not as the JSON value;
> * a {{byte[]}} body that is not valid text is decoded as text into {{data}}, which replaces every invalid byte, so the data is lost.
> In the review of #27342 Claus Ibsen listed these three as an optional follow-up; they predate CAMEL-25301.
> h3. Reproduction
> {{CloudEventJsonDataTypeTransformerTest}} (new tests), failing on main: {{shouldNotNestJsonDataOfANonJsonContentType}} ({{expected: <[1,2]> but was: <[1, 2]>}}, a JSON array), {{shouldUseTheDataContentTypeOfTheEvent}} (the {{CamelCloudEventDataContentType}} header {{text/plain}}), {{shouldNestJsonScalarsOfAJsonContentType}} ({{expected: BigDecimal<42> but was: String<42>}}), {{shouldWriteBinaryDataAsBase64}} and {{shouldWriteBytesThatAreNotValidTextAsBase64WhateverTheContentType}} (no {{data_base64}}), {{shouldWriteBytesThatAreValidTextAsStringWhenTheContentTypeIsBinary}} (a JSON {{byte[]}} body declared {{application/octet-stream}} is nested).
> h3. Proposed fix
> Decide by the {{datacontenttype}} of the event ({{CamelCloudEventDataContentType}}, 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, now including a scalar, is nested; any other body is a string (as the scan from CAMEL-25301 already does for malformed JSON). Without a content type this is the default, so the default behaviour stays: JSON objects and arrays nested, other text as a string; only scalar bodies change.
> * any other content type: the body is a string, also a JSON object or array.
> * a {{byte[]}} body that is not valid text in the charset of the exchange (UTF-8 by default), whatever the content type: {{data_base64}}. 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. Other bodies (an {{InputStream}}, a stream cache) are read as text as before.
> Controls: a JSON {{byte[]}} body under {{application/json}} is nested and a {{text/plain}} {{byte[]}} body is text, as before; malformed JSON under {{application/json}} stays a string; {{application/vnd.example+json; charset=UTF-8}} and {{Application/JSON}} are JSON; {{byte[]}} bodies are decoded in the charset of the exchange. Module: 24 tests pass.
> Impact on component data types (upgrade guide): several CloudEvent data types declare a fixed 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}} (since CAMEL-20334 for aws2-s3), {{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. This narrows the nesting of CAMEL-22339 to JSON content types. The upgrade guide says how to keep a JSON body nested (set {{CamelCloudEventDataContentType}} to {{application/json}}). No Kamelet in camel-kamelets uses {{application-cloudevents+json}} (GitHub code search, 2026-10-05); a Pipe to Knative such as the one in CAMEL-20334 uses the binary mode ({{http:application-cloudevents}}), which this does not change.
> Affected: 4.14.x, 4.18.x and main.
> Duplicate check (2026-10-05): JIRA "CloudEventJsonDataTypeTransformer" (CAMEL-25301 only), "datacontenttype" (CAMEL-25301, CAMEL-20334), "data_base64" (none). GitHub pull requests "datacontenttype": only #27342; no open PR on camel-cloudevents.
> _Filed with Claude Code on behalf of allthingssecurity._



--
This message was sent by Atlassian Jira
(v8.20.10#820010)