[ 
https://issues.apache.org/jira/browse/QPID-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15513020#comment-15513020
 ] 

Keith Wall edited comment on QPID-7409 at 9/22/16 11:37 AM:
------------------------------------------------------------

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.
# If an operation's response is compressed by the RestServlet, the 
{{Content-Encoding}} header is not set.
# {{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.
# {{X-Content-Truncated}} is currently only set for JSON content.  This seems 
arbitrary.  Why not for other content too?
 



was (Author: k-wall):
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

Reply via email to