gemmellr commented on PR #4833: URL: https://github.com/apache/activemq-artemis/pull/4833#issuecomment-1970769791
Sacrificing any of the existing widely-used working String-based correlation ID interop in favour of the non-portable little-used byte[] versions, that dont work currently, simply does not strike me as an improvement whatsoever. String based JMSCorrelationID is the _primary, required_ form of JMSCorrelationID. Its what JMS providers _must_ implement. Its the only way to correlate using the String-only JMSMessageID values. Its what people use in selectors. Its what applications just tend to use in general (I dont think I have ever come across a real world application that used the byte[], whereas I know I have come across lots that use the String). Its also what frameworks tend to use, because they simply cant depend on the byte[] method and thus avoid it. The Camel repo for example is littered with String-based setJMSCorrelationID usage, but doesnt seem to have a single setJMSCorrelationIDAsBytes usage (according to a couple searches of their git repo). Ditto for Spring. The byte[] method is optional, you do not need to implement it at all and are simply allowed to throw UnsupportedOperationException. The API expressly notes that it is non-portable to discourage its use. The TCK only has 1 test variant (only only added with JMS 2) that uses it, and it simply swallows that potential UOE and prints it is ignoring it. The method is essentially only there to support niche cases of providers that also have non-JMS clients that require a specific 'native' correlation encoding. I think I historically saw it referenced for interop with the 'non-jms' IBM MQ clients for example, as they encoded things in a certain structure with certain hex encodings etc that need to be matched. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
