A comment's full text content is serialized with the default platform encoding

[ThorbenLindhauer]

This issue was imported from JIRA:

Field	Value
JIRA Link	CAM-3035
Reporter	zZ6Eda What is this name? This pseudonym name was generated based on the user name in JIRA to protect the personal data of our JIRA users. You can use this identifier to search for issues by the same reporter.
Has restricted visibility comments	false

---

CommentEntity#getFullMessageBytes and CommentEntity#setFullMessageBytes (see https://github.com/camunda/camunda-bpm-platform/blob/master/engine/src/main/java/org/camunda/bpm/engine/impl/persistence/entity/CommentEntity.java#L54-L60) use the default platform encoding to serialize a String as a byte array. Should use the engine's default encoding instead.

Links:

[ThorbenLindhauer]

This comment was imported from JIRA and written by user @ThorbenLindhauer

---

For example:
CommentEntity uses String#getBytes() (without encoding) to write the comment content to the database. Similarly, it retrieves the String by calling "new String(byte<])". Both cases use the platform encoding, which means that a value serialized on Windows will likely not be deserialized correctly on Linux. For backwards compatibility, we cannot easily enforce that always the engine's default charset is used.

In general: Check whether there exist other occurrences of this way of converting String to byte[> and check whether they can be changed to a charset-safe way without breaking API.

[ThorbenLindhauer]

This comment was imported from JIRA and written by user @ThorbenLindhauer

---

To "fix" the above example with comments, one option could be to add a CLOB field to the Comment table that takes all the new comment values and deprecrate the old field. When deserializing a comment, it is then clear which field contains CLOBs and which must be deserialized in the current fashion.