THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| Test Case | Message |
|---|---|
| small text message | JMS TextMessage "hello world" |
| large text message | JMS TextMessage "ABCD" repeated 1024^2 16383 times (65532 length) |
| small map message | JMS MapMessage one key/value pair of each supported type. String pair value is (1) |
| large map message | JMS Map Message one key/value pair of each supported type. String pair value is (2) |
| small stream message | JMS Stream Message containing pair of each support type. String value is (1) |
| large stream message | JMS Stream Message containing pair of each support type. String value is (2) |
| small object message | JMS Object Message containing List comprising string value (1) and an integer |
| large object message | MS Object Message containing List comprising string value (2) and an integer |
large pdf file | JMS Bytes Message containing a PDF (2102551 bytes) |
...
| Test Case | Protocol 0-9/0-10 | ||
|---|---|---|---|
| Content Type | On screen preview | Content Download | |
| small text message | text/plain | complete string value | ditto preview |
| large text message | text/plain | truncated string value | complete string value |
| small map message (default) | amqp/map | Table containing name/value pairs Map entry with bytes array value is base64 encoded | The map's contents encoded as a AMQP 0-10 map
|
| large map message (default) | amqp/mapError popup 'unknown code 67' No preview displayed. Broker survives. Stack trace (1) | Table containing name/value pairs Map entry with bytes array value is array of ints | |
| small map message (legacy) | jms/map-message | Table containing name/value pairs Map entry with bytes array value is base64 encoded | Each written value is encoded by the TypedBytesContentWriter (2) |
| large map message (legacy) | jms/map-message | Table containing name/value pairs Map entry with bytes array value is array of ints | |
| small stream message | amqp/list | Table containing list values | The list's contents encoded as a AMQP 0-10 list |
| large stream message | amqp/list | Error popup 'unknown code 67' No preview displayed. Broker survives. Stack trace (1) | |
| small stream message (default - legacy) | jms/stream-message | No preview | Each written value is encoded by the TypedBytesContentWrite |
| large stream message (default - legacy) | jms/stream-message | No preview | |
| small object message | application/java-object-stream | No preview | Serialised object bytes |
| large object message | application/java-object-stream | No preview | |
large pdf file | application/octet-stream | No preview | the pdf file. |
...
- 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. Previewing the large map and large list encoded as AMQP 0-10 fails 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)
...
- The way limit applies to Json (truncating, but retaining a syntactically valid response if possible), seems surprising (at least to me).
Suggested Behaviour
...
- Server side
- Standardise on returning byte arrays as array of integers
- For operation getContent if JSON is requested, it produces it only for Strings, Maps, Collections. For any other object payload, the operation must fail (say 422)
- For AMQP 1.0
- for messages with payloads that are representable as JSON, the above changes will be sufficient give us the preview.
- for byte messages, with payloads that hold things like PDFs, there is currently no good place to adapt the content and extract the message payload. The underlying problem here is the store API. I suggest we don't fix this at the moment.
- UI
- UI always requests content JSON content with limit. If the request fails with 422, add message "preview no available" to the UI.
- UI no longer considers mime type