[ 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-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org