[
https://issues.apache.org/jira/browse/CAMEL-25360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shashank reassigned CAMEL-25360:
--------------------------------
Assignee: shashank
> 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
>
> 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)
