[
https://issues.apache.org/jira/browse/QPID-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15487312#comment-15487312
]
Lorenz Quack commented on QPID-7409:
------------------------------------
Hello Alex. Sorry it took me so long to review this.
{{AbstractQueue}}
* making the {{getMessageContent}} param {{returnJson}} default to {{true}}
breaks backwards compatibility. therefore default should be {{false}}.
* In {{getMessageContent}} why do you cast the return value of
{{getMessageReference}} to {{MessageReference}}?
* {{createMessageContent}} parameter should be generified:
{{MessageReference<?>}}
{{JsonMessageContent}}
* I think this should share code with {{AbstractQueue$MessageContent}}
* Is it correct that this does not implement the {{StreamContent}} interface?
* {{copyObject}} does not copy the object. it converts it to json and might
truncate the content.
* {{getContentDisposition}} should be shared between this and
{{AbstractQueue$MessageContent}}
* I find the way the message is truncated a little odd. For example if I am
sending a {{MapMessage}} where the first entry is
{{"foo":"largeStringLongerThan1024Bytes..."}} then the UI will say "showing the
first 1024 bytes ..." but in fact it will show nothing. The furthermore curl
has no indication that the content was truncated.
* {{null}} values in map values seem to be disallowed but in collections they
are allowed.
* {{copyString}} seems curious. The object mapper is used to covert a string
into a string I presume to account for that additional quotes it will put
around the string. In the collection and map case you simply use a constant for
that. Furthermore I think the {{limit}} calculation is off and the {{DOTS}} are
not accounted for in {{_remaining}}.
* when considering strings you seem to check first whether there is enough
space before adding it. For other objects (e.g. numbers and collections) you do
the remaining check after adding it.
* I did not test this but by looking at the code I suspect the behaviour of
{{copyMap}} might be wrong in case the key (which is converted *after* the
value) exceeds the remaining limit. I think you might end up with
{{null:"value"}} in {{copy}}.
{{MessageConverter_v0_10_to_Internal}}, {{MessageConverter_v0_8_to_Internal}},
and {{MessageCompressionTest}}
* These changes seem to be unrelated to this JIRA.
> Support preview of maps/list message content
> --------------------------------------------
>
> Key: QPID-7409
> URL: https://issues.apache.org/jira/browse/QPID-7409
> Project: Qpid
> Issue Type: Improvement
> Reporter: Keith Wall
> Assignee: Alex Rudyy
> Fix For: qpid-java-6.1
>
> Attachments:
> 0001-QPID-7409-WIP-add-support-for-getting-of-message-con.patch
>
>
> When viewing messages through the web management console, if the message is
> of type such as a list or map currently the user sees the bytes of the
> underlying AMQP datastructure. Instead, the preview area should display the
> data in a human friendly way.
> The managed operation {{Queue#getMessageContent}} will be enhanced to be
> capable of returning a message in JSON format if possible with an optional
> parameter {{returnJson}}. If rather than returning the message's content
> bytes directly, it should first convert the message to an {{InternalMessage}}
> (MessageConverterRegistry.getConverter(serverMessage.getClass,
> InternalMessage.class).convert(...)) then use the JSON serialiser to serial
> the MessageBody of the resulting internal message.
> Within the WMC, if the resulting object is of a previewable type (string,
> map, list etc) and the content is not too long, the content should be added
> to a scrollable preview pane of the message dialogue by traversing the object
> tree and producing a human readable representation of its structure and
> content. (Perhaps an approach such as
> https://stackoverflow.com/questions/13341373/render-arbitrary-json-in-html
> will help)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
