THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
(3) http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#section-message-format
Current Problems
Preview feature
- As the preview uses JSON, there is type-information loss (e.g. a list that comprises shorts in indistinguishable from a list of ints).
- The representation of byte-arrays is inconsistent between truncated and untruncated previews (Base64 vs JSON array of integers),
- A byte array serialised as Base64 may be misinterpreted as a String. When viewing a preview of a message with a structured payload included a byte-array, the representation differs between truncated and untruncated views (JSON list vs Base64)
- Previewing the large map and large list encoded as AMQP 0-10 fails in within the internal message conversion (why?)
- As we already offer a preview of the amqp/lists is seems odd that the same is not offered for the jms/stream-message
- AMQP 1.0 doesn't offer any previews (because the server currently only obeys returnJson if the message carries a known AMQP 0-8..0-10 mime type)
Content Download
- In AMQP 0-8..0-10, getContent is useful for bytes/text/object messages. For users of AMQP 1.0, the getContent returns the concatenation of the immutable 'bare message' which is useless to the end user (unless they are prepared to decode the AMQP).
API
- The way limit applies to Json (truncating, but retaining a syntactically valid response if possible), seems surprising (at least to me).
Suggested Behaviour