tabish121 commented on PR #4833: URL: https://github.com/apache/activemq-artemis/pull/4833#issuecomment-1970070993
> Perhaps our hands are tied here and we just can't support OpenWire correlation ID as `byte[]` since it will break existing use-cases. I'm running the full test-suite now, and if there are existing test-cases that break then that will help convince me. However, at this point it seems to me like using `byte[]` to gain compatibility between JMS and a "native" format (e.g. core) is actually the right thing to do so supporting `byte[]` across all protocols at the sacrifice of `String` is appropriate especially since this will open the door to compatibility with MQTT 5 (although I grant that's likely an edge case). > > I'm, of course, open to being convinced otherwise. I'd love your thoughts. Given what Openwire does (treats all correlation IDs as String even the byte[] ones) I'd have chosen to keep incoming Openwire message correlation IDs as String upon conversion to Core as you have no visibility into what it started as but most likely guess is probably that it was a String (set from getJMSMessageID). On the outbound from AMQP / Core / MQTT to Openwire you could UTF-8 encode any binary value as Openwire again is not making it clear what the source value started as and it is just going to UTF8 decode it when you call getJMSCorrelationIDAsBytes Core and AMQP actually won't return anything (Qpid JMS will throw) from getJMSCorrelationIDAsBytes if it didn't arrive as a byte[] but that seems a semi-reasonable outcome when going from Openwire to Core / AMQP as again Openwire gives you not hint as to what it was at the start so failing on getJMSCorrelationIDAsBytes for that case is reasonable. -- 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: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
