[jira] [Commented] (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=16141733#comment-16141733 ] ASF subversion and git services commented on QPID-7434: --- Commit b9032e9d671962a4ea7fc0b62cc5778ed927a5d6 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=b9032e9 ] QPID-7434: [Java Broker] Fix AMQP 0-8 to 1.0 replyTo conversion when replyTo is not set > 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
[jira] [Commented] (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=16138515#comment-16138515 ] ASF subversion and git services commented on QPID-7434: --- Commit d12b40a4d066d79e5dc38b7b137a73b776817f0a in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=d12b40a ] QPID-7434: [Java Broker] Fix AMQP 0-10 to 1.0 correlationId conversion > 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
[jira] [Commented] (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=16125666#comment-16125666
]
Keith Wall commented on QPID-7434:
--
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
[jira] [Commented] (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=16123395#comment-16123395 ] ASF subversion and git services commented on QPID-7434: --- Commit 385167e1f6085aceddb2ded398ad504bb40aed98 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=385167e ] QPID-7434: [Java Broker] Improve handling of empty map/stream messages. > 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
[jira] [Commented] (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=16123397#comment-16123397 ] ASF subversion and git services commented on QPID-7434: --- Commit 17e6c7d6e070ecfa8a46edb643607b0c6ef9d099 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=17e6c7d ] QPID-7434: [Java Broker] Improve Internal to AMQP 0-x message conversion and add unit tests > 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
[jira] [Commented] (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=16123396#comment-16123396 ] ASF subversion and git services commented on QPID-7434: --- Commit 939cda5bf529bc0ecf911f6af586eb48573bbcca in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=939cda5 ] QPID-7434: [Java Broker] Improve AMQP 0-x to Internal conversion and add unit tests. > 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
[jira] [Commented] (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=16123068#comment-16123068 ] ASF subversion and git services commented on QPID-7434: --- Commit 4f43a9bc760574639311f0ad773105c7dde879ae in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=4f43a9b ] QPID-7434: [Java Broker] Remove invalid test > 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
[jira] [Commented] (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=16121852#comment-16121852 ] ASF subversion and git services commented on QPID-7434: --- Commit 2e809efccb6d431a413c9497b6785a16cfb4d668 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=2e809ef ] QPID-7434: [Java Broker] Improve AMQP 1.0 to Internal content conversion and add unit tests > 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
[jira] [Commented] (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=16121378#comment-16121378 ] ASF subversion and git services commented on QPID-7434: --- Commit 84256b2c718a06490a7a7650c1eb0875c03dc9d4 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=84256b2 ] QPID-7434: [Java Broker] Improve Internal to AMQP 1.0 content conversion and add unit tests > 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
[jira] [Commented] (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=16119900#comment-16119900 ] ASF subversion and git services commented on QPID-7434: --- Commit 20c9c58c9469abd6398f16644c5b0e5c751a06dc in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=20c9c58 ] QPID-7434: [Java Broker] Improve AMQP 0-8 to 1.0 content conversion and unit tests > 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
[jira] [Commented] (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=16119901#comment-16119901 ] ASF subversion and git services commented on QPID-7434: --- Commit 13c9e7e668f9c09c796981135433099a6946f2e4 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=13c9e7e ] QPID-7434: [Java Broker] Improve AMQP 0-10 to 1.0 content conversion and add unit tests > 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
[jira] [Commented] (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=16118157#comment-16118157 ] ASF subversion and git services commented on QPID-7434: --- Commit d9027a0b9b20d3fa81450eb46cd46789dad506ab in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=d9027a0 ] QPID-7434: [Java Broker] Improve AMQP 1.0 to 0-10 content conversion and add unit tests > 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
[jira] [Commented] (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=16116765#comment-16116765 ] ASF subversion and git services commented on QPID-7434: --- Commit a4a17517312350831b797fa817ebbc2bbe1ee735 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=a4a1751 ] QPID-7434: [Java Broker] improve AMQP 1.0 to 0-8 content conversion and add unit tests > 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
[jira] [Commented] (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=16114100#comment-16114100 ] ASF subversion and git services commented on QPID-7434: --- Commit b469c454a00997e0e83858673b92895af85f1dd4 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=b469c45 ] QPID-7434: [Java Broker] explicitly specify encoding when converting String <-> byte[] > 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
[jira] [Commented] (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=16111063#comment-16111063 ] ASF subversion and git services commented on QPID-7434: --- Commit 344b01e6eca5271df92f36b73060d93353c57f4d in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=344b01e ] QPID-7434: Rename test > 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
[jira] [Commented] (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=16111064#comment-16111064 ] ASF subversion and git services commented on QPID-7434: --- Commit ee9e140e38e551081e5bb046be57df5728003a03 in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=ee9e140 ] QPID-7434: Add missing properties conversion for message conversion layer from internal to 0-10 and add unit tests > 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
[jira] [Commented] (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=16110870#comment-16110870 ] ASF subversion and git services commented on QPID-7434: --- Commit fdff8c5f2dd2285eb1e73f53c3bd4b6886d6aa89 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=fdff8c5 ] QPID-7434: Add unit tests for property conversion of AMQP 0-10 messages to internal messages > 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
[jira] [Commented] (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=16109171#comment-16109171 ] ASF subversion and git services commented on QPID-7434: --- Commit 392187c183c5b4c8e897aced80ef5e3933be39f5 in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=392187c ] QPID-7434: Add unit tests for property conversion of AMQP 0-8..0-9-1 messages to internal messages > 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
[jira] [Commented] (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=16109172#comment-16109172 ] ASF subversion and git services commented on QPID-7434: --- Commit 8ab67e0c145b5a18df424c829e99b47b63d65726 in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=8ab67e0 ] QPID-7434: Add unit tests for property conversion of internal messages to AMQP 0-8 messages > 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
[jira] [Commented] (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=16109170#comment-16109170 ] ASF subversion and git services commented on QPID-7434: --- Commit 04b19e96b30e92d2270458c86381d356726cc76d in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=04b19e9 ] QPID-7434: Add unit tests for property conversion of internal messages to AMQP 1.0 messages > 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
[jira] [Commented] (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=16108800#comment-16108800 ] ASF subversion and git services commented on QPID-7434: --- Commit 4a2d8895778da7042c3a0f6cdc0523253990013d in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=4a2d889 ] QPID-7434: Add unit tests for conversion of AMQP 1.0 message properties into internal format > 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
[jira] [Commented] (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=16107494#comment-16107494 ] ASF subversion and git services commented on QPID-7434: --- Commit a94d6ffe8e3afee7cf5e4db5ef061fbf432f8524 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=a94d6ff ] QPID-7434: Add missing properties conversion for message conversion layer from 1.0 to 0-10 and add unit tests * also fix some 1.0 to 0-8 conversion issues > 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
[jira] [Commented] (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=16105081#comment-16105081 ] ASF subversion and git services commented on QPID-7434: --- Commit 47ac14c69b0cb6ab12e18c635973ef9adccde691 in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=47ac14c ] QPID-7434: Fix failing test > 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
[jira] [Commented] (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=16105050#comment-16105050 ] ASF subversion and git services commented on QPID-7434: --- Commit 5489d616fc41d2aced7ad9db4338595fbb974ac3 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=5489d61 ] QPID-7434: Add missing properties conversion for message conversion layer from 1.0 to 0-8 and add unit tests * also some fixes for 0-10 to 0-8 conversion > 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
[jira] [Commented] (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=16103287#comment-16103287 ] ASF subversion and git services commented on QPID-7434: --- Commit 9d8a05cd72e4877a217024f3df5e40a8f9c45b37 in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=9d8a05c ] QPID-7434: Verify that illegal key or values are not included into application-properties on conversion from 0-8 into 1.0 > 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
[jira] [Commented] (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=16103289#comment-16103289 ] ASF subversion and git services commented on QPID-7434: --- Commit bfb48c7a2e9841d60cdd8f6cc9597acf2106f7dc in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=bfb48c7 ] QPID-7434: Fix handling of default destination on conversion from 0-8 > 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
[jira] [Commented] (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=16103290#comment-16103290 ] ASF subversion and git services commented on QPID-7434: --- Commit f3fad41d3e3c2270b625e6cdf89733ed72a835dd in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=f3fad41 ] QPID-7434: Add missing properties conversion for message conversion layer from 0-10 to 0-8 > 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
[jira] [Commented] (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=16103288#comment-16103288 ] ASF subversion and git services commented on QPID-7434: --- Commit 46983ff02aa25598af689e024cffbd9b773b8b2b in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=46983ff ] QPID-7434: Add missing properties conversion for message conversion layer from 0-10 to 1.0 and add unit tests > 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
[jira] [Commented] (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=16101541#comment-16101541 ] ASF subversion and git services commented on QPID-7434: --- Commit ebec2d335cdded5896477640bfa7b1c322d0cbdb in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=ebec2d3 ] QPID-7434: Add missing properties conversion for message conversion layer from 0-8 to 0-10 and add unit tests > 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 > 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
[jira] [Commented] (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=16101228#comment-16101228 ] ASF subversion and git services commented on QPID-7434: --- Commit 3ecdc824a65139e11523ba8fa21ba35520b83feb in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=3ecdc82 ] QPID-7434: Add missing properties conversion for message conversion layer from 0-8 to 1-0 and add unit tests > 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 > 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
[jira] [Commented] (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=16101227#comment-16101227 ] ASF subversion and git services commented on QPID-7434: --- Commit 61066b27f6a5776808c478fd2ce49ffc47468a60 in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=61066b2 ] QPID-7434: Move tests into canonical location > 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 > 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
[jira] [Commented] (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=16032736#comment-16032736 ] Keith Wall commented on QPID-7434: -- When converting a AMQP 0-8..0-10 messages with zero length content for AMQP 1.0, the conversion layer should be be careful to respect the AMQP 1.0 specification with regard to forming a valid message body. See: http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#section-message-format > 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 > 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.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (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=16013896#comment-16013896 ] Keith Wall commented on QPID-7434: -- We notice that the from 0-10 conversion classes do not guard against null 0-10 header e.g. org.apache.qpid.server.protocol.v0_10.MessageConverter_v0_10_to_Internal#convert > 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 > Fix For: qpid-java-broker-7.0.0 > > > There are a number of gaps in our message converters that mean some message > are not converters 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.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
