GitHub user mattrpav edited a discussion: Path forward for full UTF-8 correctness
## Background As reported here: https://github.com/apache/activemq/issues/2644 and spot fixed previously, ActiveMQ currently has incomplete coverage of the entire UTF-8 range when working with text-bodied messages. ## Challenges with fixing it 1. Fixing it would mean potentially breaking existing users that have work arounds in place. 2. All clients and all brokers in the message flow path must be aligned or there is potential for issues. There is no iterative rollout option and rollback is everyone all at once. 3. Across protocol impacts: Non-OpenWire clients may be coded to work-around (AMQP, STOMP, etc) ## Approaches A couple fix options: 1. Use a env/sys property to enable proper UTF-8 rendering. Have a static code block that detects and then sets a flag to route desired behavior 2. Force fixed behavior as part of OpenWire v13 3. Make the ‘fixed’ behavior the default in ActiveMQ 7 and/or a combination of ActiveMQ 7 and OpenWire v13 4. Offer a env/sys flag to rollback to previously ‘incorrect’ behavior 5. Add an 'upgrade check' certification tool to analyze existing message stores for messages relying on modified UTF-8. ## Motivation Usage of Emoji (and potentially other uses of UTF-8 character range) will only increase across applications. GitHub link: https://github.com/apache/activemq/discussions/2658 ---- 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
