allthingssecurity opened a new pull request, #27984: URL: https://github.com/apache/camel/pull/27984
# Description [CAMEL-25699](https://issues.apache.org/jira/browse/CAMEL-25699) The protobuf data format can give the unmarshalled message as a `Map` (`getBody(Map.class)`, the type converter added by CAMEL-14192), and it can marshal a `Map`. `ProtobufConverter.convertValueToSuitableFieldType` handled a `bytes` field like an enum, with `value.toString()`. For an enum that is the constant name, but for a `bytes` field the value is a `ByteString`, and `ByteString.toString()` is a description for logging (`<ByteString@3a03464 size=4 contents="\001\002\003\377">`, with a preview that is shortened for long values). So the content of every `bytes` field was replaced by that text, without an error. In the other direction, a `byte[]` for a `bytes` field was passed to `Builder.setField` unchanged and protobuf rejected it, so no `Map` form of a `bytes` field could be marshalled. Change (`ProtobufConverter`): - message to `Map`: a `bytes` field becomes `ByteString.toByteArray()`; enums are unchanged; - `Map` to message: a `byte[]` for a `bytes` field is wrapped with `ByteString.copyFrom`; a `ByteString` is passed through as before, other types fail as before. What users can notice: the `Map` holds a `byte[]` for a `bytes` field instead of a `String`. The 4.24 upgrade guide gets a short note. Tests: - New `ProtobufBytesFieldMapTest` (3 tests), using the well-known type `com.google.protobuf.BytesValue` (one `bytes` field, shipped with protobuf-java, so the test protos are unchanged) and a 61-byte value that is not valid UTF-8: - `toMap` gives the bytes of the field; - `toProto(toMap(message))` gives the same message; - a route that unmarshals the native bytes, then `getBody(Map.class)`, gives the bytes of the field. - Without the change all three fail: 3 run, 3 errors (`ClassCastException: class java.lang.String cannot be cast to class [B` for the two `Map` reads, `IllegalArgumentException: argument type mismatch` from `setField` for the round trip). - With the change the camel-protobuf tests pass: 19 run, 0 failures, 0 errors, 0 skipped (16 existing and the 3 new ones). What is 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; that is loud and a separate question. - Map fields stay a list of `key` / `value` maps, as before. What was not run: the full root build. # 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): [CAMEL-25699](https://issues.apache.org/jira/browse/CAMEL-25699). # 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 camel-protobuf, 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 commit carries 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]
