GitHub user jbonofre added a comment to the discussion: Path forward for full UTF-8 correctness
Thanks Matt! I think the options combine rather than compete. I suggest this path: 1. Tie the fix to OpenWire v13 negotiation. This is the only approach that addresses the "all clients and brokers must align" constraint. WireFormatInfo already negotiates the version, so a v13 connection would use correct UTF-8 and older connections would keep the legacy encoding. 2. Make it the default in ActiveMQ 7. Changing the bytes on the wire can break users who have workarounds, so it should be in a major version (with a Release Note 😄 ). 3. We should probably keep a rollback flag for least one major version. It's cheap, and it gives workaround users an escape hatch. 4. I think a JVM-wide static flag brings back the "everyone at once, rollback is everyone at once" problem, so I would not make it the primary mechanism. It opens more questions: - The messages already stored (KahaDB, JDBC, ...) were written with the legacy encoding. We need to decide whether the stores keep the original bytes or re-marshal, and make sure old data is still readable after the switch. - AMQP and STOMP presumably already use standard UTF-8. We should test bridging in both directions, so that clients with workarounds don't see double-encoded data. - A log warning or metric when the legacy encoder sees a supplementary character, would let operators find out whether they are affected before the default changes. - NMS and the others would need a matching change keyed off the same version negotiation. GitHub link: https://github.com/apache/activemq/discussions/2658#discussioncomment-18902802 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
