You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (JIRA)" <ji...@apache.org> on 2017/08/14 13:17:03 UTC
[jira] [Comment Edited] (QPID-7434) Mature the AMQP message
conversion layer (headers and content)
[ https://issues.apache.org/jira/browse/QPID-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125666#comment-16125666 ]
Keith Wall edited comment on QPID-7434 at 8/14/17 1:16 PM:
-----------------------------------------------------------
I notice that the conversion layer currently does not take into account {{JMS_QPID_DESTTYPE}} which is used to help tAMQP 0-x Qpid JMS Client reconstitute the {{Message#JMSDestination}} when BURLs are in use. It would be possible of the Broker's conversion layer to add this hint when converting from 0-8..0-91, but I don't think this is required. The existing client code already has a fallback {{AbstractAMQMessageDelegate#generateDestination}} which is used when the {{JMS_QPID_DESTTYPE}} is absent. This should given usable address, which is probably good enough for most use-cases.
was (Author: k-wall):
I notice that the conversion layer currently does not take into account {{JMS_QPID_DESTTYPE}} which is used to help the 0-8..91 path of the AMQP 0-x Qpid JMS Client reconstitute the {{Message#JMSDestination}} when BURLs are in use. It would be possible of the Broker's conversion layer to add this hint when converting from 0-8..0-91, but I don't think this is required. The existing client code already has a fallback {{AbstractAMQMessageDelegate#generateDestination}} which is used when the {{JMS_QPID_DESTTYPE}} is absent. This should given usable address, which is probably good enough for most use-cases.
> Mature the AMQP message conversion layer (headers and content)
> --------------------------------------------------------------
>
> Key: QPID-7434
> URL: https://issues.apache.org/jira/browse/QPID-7434
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Keith Wall
> Assignee: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> There are a number of gaps in our message converters that mean some message are not converted with complete fidelity (particularly in the treatment of application headers), and where complete fidelity cannot be acheived we need sensible rules, uniformly implemented to decide how aspects degrade.
> For instance, for AMQP 0-8..0-10 allow application headers whose values were complex types (e.g. map). AMQP 1.0 disallows this. What should the behaviour be? Should the header be dropped?
> Another instance is the length and constituency of the keys of application headers. AMQP 0-8..0-10 have a protocol restriction of 255 UTF8 bytes. AMQP has supports longer strings. Also AMQP 0-9 says further restricts the key to be formed like a Java identifier.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org