[
https://issues.apache.org/jira/browse/QPID-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15513020#comment-15513020
]
Keith Wall commented on QPID-7409:
----------------------------------
I think this still has problems:
# {{AbstractQueue.MessageContent#release}} is an unnecessary override. I think
{{AbstractQueue.BaseMessageContent#release}} ought to be final.
# AbstractServlet.java:353 calls CONTENT_ENCODING_HEADER.toUpperCase() when
accessing the headers map, but a few lines later, we access the headers map
again (357) without upper-casing the name.
# We treat the map returned by
{{org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet#getResponseHeaders}}
as mutable, but this is not always the case. If the Content yields no
headers, the map will be immutable.
# {{X-Content-Limit}} looks really confused. What is the intention here? Is
it that we intend this to form part of the REST API?? If so - why, as a caller
I told you the limit so telling me what I told you seems pointless. At the
moment it looks like it might be a kludge so that the REST layer can see what
limit was requested. This seems horrid. I think the nub of the problem is
responsibilities around the imposition of limit are confused. Either the limit
should be the sole responsibility of REST API, or it should be sole
responsibility of the operation. I am not sure which I dislike least.
> 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: Keith Wall
> 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
