GitHub user cshannon added a comment to the discussion: Path forward for full UTF-8 correctness
@livicitu - That is a good idea, if we can handle it on the read side and detect the format but I'm not sure that works in all cases because of legacy clients. I think everyone agrees that the ultimate goal should just be using standard UTF-8 everywhere, but the hold up is just backwards compatibility. If we can fallback and detect the old legacy modified format transparently and convert that makes it easier as things won't break if here is the old format and no conversion needed. This would let the broker handle both java openwire and current encoding as well as other clients like stomp/amqp that send standard UTF-8 (or even as you noted other openwire clients) However, older java clients would potentially break right? They would not be able to always decode standard UTF-8 byte case without an update. There's also still the problem of consumers for other protocols. If readUTF8() can handle both formats, then a stomp or AMQP producer doesn't need conversion and the bytes can be stored as is. But we still need to convert for a stomp/amqp consumer because we might have the modified format that they wouldn't be able to read. GitHub link: https://github.com/apache/activemq/discussions/2658#discussioncomment-18950351 ---- 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
