This is really annoying...
For instance, if you run JBoss Testsuite on a Linux box, you will see things like this happening (look at the attached picture).
We could do something that would still be performant, and maybe convert it back to a readable String before printing. It doesn't need to be this annoying.
@Tim: Actually you're the only one who still likes it ;-)
Clebert Suconic wrote:
@Tim: Actually you're the only one who still likes it ;-)
Did you actually bother to read my last post on this thread?
Apologize.. My Bad!
The quick solution for the output from the tests could be to change the line "sb.append(getJMSMessageID());" in HornetQMessage.toString() to something like "sb.append(makeReadable(getJMSMessageID()));" to comply with this requirement of Object.toString(): "The result should be a concise but informative representation that is easy for a person to read." - http://java.sun.com/javase/6/docs/api/java/lang/Object.html#toString()
I thought that it would be easy to make HornetQMessage.getJMSMessageID() return readable string directly, but Tim pointed me to a problem with message selectors: they could contain the readable message ID returned from getJMSMessageID(), which would need to be converted back to the core representation (to make the filter work properly at the server).
I still think that it would be doable, though - basically keep byte[] in the core message, and do the proper transformation to String when transported to the JMS client - prepend with "ID:" and follow with the encoded content of byte[] (base64 for example). Do the reverse transformation from String to byte[] when needed.