[
https://issues.apache.org/jira/browse/ARTEMIS-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erwin Dondorp updated ARTEMIS-3584:
-----------------------------------
Description:
A message payload can be viewed in a few different ways: text, hexadecimal
bytes and decimal bytes, or a combination of these. However, when a message
payload follows the internal structure of its protocol, it is indistinguishable
whether the text that is shown is the actual payload for a text message, or the
representation for a structured message.
I'm proposing a new visualisation, in which multiple (relevant) representations
of the message payload are shown in a tabbed area. Basically the tabs are added
to the message description and message payload fields that already exist.
Selecting a tab will just replace the content of these 2 fields.
The following tabs are proposed:
* Text
* Hex
* Decimal
* AMQP
* Large
* Compressed
The first 3 (Text/Hex/Decimal) are always visible. The "Text" tab is only
active when the message has an actual text payload, otherwise it is inactive.
The Hex and Decimal tabs are always active, except for large messages. The last
3 tabs (AMQP/Large/Compressed) are only visible when the message-payload is of
that type. The AMQP tab shows the simple AMQP data structure in a JSON-like
notation, and the Large and Compressed tabs just inform the user that the
message is large or compressed. Using 3 separate tabs for this quickly informs
the user that the text that is shown is a representation and not the actual
text.
All relevant representations are generated on the server-side, including the
hex and decimal representations that previously were constructed on the
gui-side.
The construction of representations that are similar between the message
protocols is now shared code. this applies to text/hex/binary.
The preferences option "Browse Bytes Messages" is now removed. Instead, the
system will remember the last representation that was used. otherwise the first
active representation is selected.
A first look:
!screenshot-2.png!
TODO:
* test with all protocols and all message types
* cleanup
It may take a while before the matching PR is ready...
was:
A message payload can be viewed in a few different ways: text, hexadecimal
bytes and decimal bytes, or a combination of these. However, when a message
payload follows the internal structure of its protocol, it is indistinguishable
whether the text that is shown is the actual payload for a text message, or the
representation for a structured message.
I'm proposing a new visualisation, in which multiple (relevant) representations
of the message payload are shown in a tabbed area. Basically the tabs are added
to the message description and message payload fields that already exist.
Selecting a tab will just replace the content of these 2 fields.
The following tabs are proposed:
* Text
* Hex
* Decimal
* AMQP
* Large
* Compressed
The first 3 (Text/Hex/Decimal) are always visible. The "Text" tab is only
active when the message has an actual text payload, otherwise it is inactive.
The Hex and Decimal tabs are always active, except for large messages. The last
3 tabs (AMQP/Large/Compressed) are only visible when the message-payload is of
that type. The AMQP tab shows the simple AMQP data structure in a JSON-like
notation, and the Large and Compressed tabs just inform the user that the
message is large or compressed. Using 3 separate tabs for this quickly informs
the user that the text that is shown is a representation and not the actual
text.
All relevant representations are generated on the server-side, including the
hex and decimal representations that previously were constructed on the
gui-side.
The construction of representations that are similar between the message
protocols is now shared code. this applies to text/hex/binary.
The preferences option "Browse Bytes Messages" is now removed. Instead, the
system will remember the last representation that was used. otherwise the first
active representation is selected.
A first look:
!screenshot-2.png!
TODO:
* replace the button-row with a tab-bar; with the current selection highlighted
* remember previous selection(s) in LRU order
* fix all texts
* test, test, test
* cleanup, cleanup, cleanup
It may take a while before the matching PR is ready...
> show multiple representations of the payload on "Browse Queue"
> --------------------------------------------------------------
>
> Key: ARTEMIS-3584
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3584
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Web Console
> Affects Versions: 2.19.0
> Reporter: Erwin Dondorp
> Priority: Minor
> Attachments: screenshot-2.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> A message payload can be viewed in a few different ways: text, hexadecimal
> bytes and decimal bytes, or a combination of these. However, when a message
> payload follows the internal structure of its protocol, it is
> indistinguishable whether the text that is shown is the actual payload for a
> text message, or the representation for a structured message.
> I'm proposing a new visualisation, in which multiple (relevant)
> representations of the message payload are shown in a tabbed area. Basically
> the tabs are added to the message description and message payload fields that
> already exist. Selecting a tab will just replace the content of these 2
> fields.
> The following tabs are proposed:
> * Text
> * Hex
> * Decimal
> * AMQP
> * Large
> * Compressed
> The first 3 (Text/Hex/Decimal) are always visible. The "Text" tab is only
> active when the message has an actual text payload, otherwise it is inactive.
> The Hex and Decimal tabs are always active, except for large messages. The
> last 3 tabs (AMQP/Large/Compressed) are only visible when the message-payload
> is of that type. The AMQP tab shows the simple AMQP data structure in a
> JSON-like notation, and the Large and Compressed tabs just inform the user
> that the message is large or compressed. Using 3 separate tabs for this
> quickly informs the user that the text that is shown is a representation and
> not the actual text.
> All relevant representations are generated on the server-side, including the
> hex and decimal representations that previously were constructed on the
> gui-side.
> The construction of representations that are similar between the message
> protocols is now shared code. this applies to text/hex/binary.
> The preferences option "Browse Bytes Messages" is now removed. Instead, the
> system will remember the last representation that was used. otherwise the
> first active representation is selected.
> A first look:
> !screenshot-2.png!
> TODO:
> * test with all protocols and all message types
> * cleanup
> It may take a while before the matching PR is ready...
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
