[
https://issues.apache.org/jira/browse/CAMEL-25699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-25699 started by shashank.
----------------------------------------
> camel-protobuf - converting a message to a Map replaces the value of every
> bytes field with the text of ByteString.toString() (size and a shortened,
> escaped preview), so the data of the field is lost
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25699
> URL: https://issues.apache.org/jira/browse/CAMEL-25699
> Project: Camel
> Issue Type: Bug
> Reporter: shashank
> Assignee: shashank
> Priority: Major
>
> The protobuf data format documents that the result of an unmarshal can be
> read as a {{Map}} ({{exchange.getMessage().getBody(Map.class)}}, the type
> converter {{ProtobufTypeConverter.toMap}} added by CAMEL-14192), and that a
> {{Map}} can be marshalled.
> {{ProtobufConverter.convertValueToSuitableFieldType}} (main d46d51c24550,
> lines 159-162) handles a {{bytes}} field together with an enum field:
> {{result = value.toString()}}. For an enum that is the name of the constant.
> For a {{bytes}} field the value is a {{com.google.protobuf.ByteString}}, and
> {{ByteString.toString()}} does not return the content; it returns a
> description for logging, for example
> {noformat}
> <ByteString@3a03464 size=4 contents="\001\002\003\377">
> {noformat}
> with the identity hash code, the size and an escaped preview that
> protobuf-java shortens for long values. So every {{bytes}} field of the
> message (also in nested messages and repeated fields) reaches the route as
> such a {{String}}; the data of the field cannot be recovered from it, and
> nothing fails or is logged.
> The other direction fails loudly: {{ProtobufConverter.toProto}} passes a
> {{byte[]}} value for a {{bytes}} field to {{Builder.setField}} unchanged, and
> protobuf rejects it ({{IllegalArgumentException}}), so there is no {{Map}}
> form of a {{bytes}} field that can be marshalled.
> Trigger: any message type with a {{bytes}} field (a common type for binary
> payloads, hashes, ids, encrypted data) and the documented {{Map}} output:
> {{unmarshal().protobuf(...)}} with {{contentTypeFormat=native}} (default)
> followed by {{getBody(Map.class)}} or {{convertBodyTo(Map.class)}}, or any
> other use of the {{Message}} to {{Map}} type converter.
> h3. Reproduction
> New {{ProtobufBytesFieldMapTest}} with the well-known type
> {{com.google.protobuf.BytesValue}} (one {{bytes}} field named {{value}}, part
> of protobuf-java, so the test protos are not changed), a value of 61 bytes:
> * {{ProtobufConverter.toMap}}: on main the value is a {{String}}, not the
> bytes ({{ClassCastException: class java.lang.String cannot be cast to class
> [B}});
> * a route {{from("direct:unmarshal").unmarshal(new
> ProtobufDataFormat(BytesValue.getDefaultInstance()))}}, then
> {{getBody(Map.class)}}: the same;
> * {{toProto(toMap(message))}}: fails on main ({{IllegalArgumentException:
> argument type mismatch}} from {{setField}}).
> With the fix the three tests pass, and the camel-protobuf tests: 19 run, 0
> failures, 0 errors, 0 skipped.
> h3. Proposed fix
> * {{convertValueToSuitableFieldType}}: a {{bytes}} field becomes
> {{ByteString.toByteArray()}} ({{byte[]}}); enums are unchanged.
> * {{getSuitableFieldValue}}: a {{byte[]}} value for a {{bytes}} field is
> wrapped with {{ByteString.copyFrom}}; a {{ByteString}} is passed as before,
> other types fail as before.
> Users can notice that the {{Map}} now holds a {{byte[]}} for a {{bytes}}
> field instead of a {{String}}; a short note goes into the 4.24 upgrade guide.
> How it was found: reading the data format converters while sweeping byte and
> size handling in data formats (round r29, track H, whose other tools were Z3
> models of retry and back-off arithmetic); the conversion has no arithmetic,
> so there is no model, the tests are the evidence. A small Java probe with
> protobuf-java 4.35.1 (the version of the parent pom) printed {{value
> BYTE_STRING -> <ByteString@3a03464 size=4 contents="\001\002\003\377">}}.
> Not changed: an {{int64}} field given an {{Integer}} in the {{Map}} (or a
> {{float}} field given a {{Double}}) is still rejected by protobuf with an
> exception (loud, separate question); map fields stay a list of
> {{key}}/{{value}} maps.
> Affected: main (d46d51c24550; tested). camel-4.23.x, camel-4.22.x,
> camel-4.18.x and camel-4.14.x have the same lines 160-162 (read, not run).
> Duplicate check (2026-10-16): JIRA text "protobuf" with "ByteString", "bytes"
> or "toMap" (CAMEL-14192, the feature; CAMEL-24170, the July 2026 data format
> review umbrella, whose protobuf items are the JSON charset, the Jackson
> timezone and the class resolver, not this); GitHub pull requests "protobuf
> ByteString", "camel-protobuf map" (nothing related).
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
