[jira] [Assigned] (QPID-7833) Batch file for Windows is missing from source distribution

2017-07-26 Thread Justin Ross (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross reassigned QPID-7833:
-

Assignee: Justin Ross  (was: Irina Boverman)

> Batch file for Windows is missing from source distribution
> --
>
> Key: QPID-7833
> URL: https://issues.apache.org/jira/browse/QPID-7833
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Affects Versions: qpid-python-1.36.0
>Reporter: Justin Ross
>Assignee: Justin Ross
>  Labels: patch
> Fix For: qpid-python-1.37.0
>
> Attachments: QPID-7833-Added-.bat-file.patch
>
>
> Reported on the user list:
> http://qpid.2158936.n2.nabble.com/qpid-python-test-bat-does-not-exist-tt7664284.html



--
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] [Updated] (QPID-7833) Batch file for Windows is missing from source distribution

2017-07-26 Thread Justin Ross (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-7833:
--
Labels: patch  (was: )

> Batch file for Windows is missing from source distribution
> --
>
> Key: QPID-7833
> URL: https://issues.apache.org/jira/browse/QPID-7833
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Affects Versions: qpid-python-1.36.0
>Reporter: Justin Ross
>Assignee: Irina Boverman
>  Labels: patch
> Fix For: qpid-python-1.37.0
>
> Attachments: QPID-7833-Added-.bat-file.patch
>
>
> Reported on the user list:
> http://qpid.2158936.n2.nabble.com/qpid-python-test-bat-does-not-exist-tt7664284.html



--
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] [Updated] (QPID-7833) Batch file for Windows is missing from source distribution

2017-07-26 Thread Irina Boverman (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Irina Boverman updated QPID-7833:
-
Flags: Patch

> Batch file for Windows is missing from source distribution
> --
>
> Key: QPID-7833
> URL: https://issues.apache.org/jira/browse/QPID-7833
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Affects Versions: qpid-python-1.36.0
>Reporter: Justin Ross
>Assignee: Irina Boverman
> Fix For: qpid-python-1.37.0
>
> Attachments: QPID-7833-Added-.bat-file.patch
>
>
> Reported on the user list:
> http://qpid.2158936.n2.nabble.com/qpid-python-test-bat-does-not-exist-tt7664284.html



--
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-7833) Batch file for Windows is missing from source distribution

2017-07-26 Thread Irina Boverman (JIRA) 

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

Irina Boverman commented on QPID-7833:
--

Added a patch.

> Batch file for Windows is missing from source distribution
> --
>
> Key: QPID-7833
> URL: https://issues.apache.org/jira/browse/QPID-7833
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Affects Versions: qpid-python-1.36.0
>Reporter: Justin Ross
>Assignee: Irina Boverman
> Fix For: qpid-python-1.37.0
>
> Attachments: QPID-7833-Added-.bat-file.patch
>
>
> Reported on the user list:
> http://qpid.2158936.n2.nabble.com/qpid-python-test-bat-does-not-exist-tt7664284.html



--
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] [Updated] (QPID-7833) Batch file for Windows is missing from source distribution

2017-07-26 Thread Irina Boverman (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Irina Boverman updated QPID-7833:
-
Attachment: QPID-7833-Added-.bat-file.patch

> Batch file for Windows is missing from source distribution
> --
>
> Key: QPID-7833
> URL: https://issues.apache.org/jira/browse/QPID-7833
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Affects Versions: qpid-python-1.36.0
>Reporter: Justin Ross
>Assignee: Irina Boverman
> Fix For: qpid-python-1.37.0
>
> Attachments: QPID-7833-Added-.bat-file.patch
>
>
> Reported on the user list:
> http://qpid.2158936.n2.nabble.com/qpid-python-test-bat-does-not-exist-tt7664284.html



--
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] [Assigned] (QPID-7871) Batch file for Windows is missing from source distribution (qpid-tools 1.36.0)

2017-07-26 Thread Justin Ross (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross reassigned QPID-7871:
-

Assignee: Justin Ross  (was: Irina Boverman)

> Batch file for Windows is missing from source distribution (qpid-tools 1.36.0)
> --
>
> Key: QPID-7871
> URL: https://issues.apache.org/jira/browse/QPID-7871
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Affects Versions: qpid-cpp-1.36.0
>Reporter: Irina Boverman
>Assignee: Justin Ross
>  Labels: patch
> Fix For: qpid-cpp-1.37.0
>
> Attachments: QPID-7871-Added-.bat-files.patch
>
>
> Reported here:
> http://qpid.2158936.n2.nabble.com/qpid-tools-on-PyPi-tc7665012.html#none



--
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] [Updated] (QPID-7871) Batch file for Windows is missing from source distribution (qpid-tools 1.36.0)

2017-07-26 Thread Justin Ross (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-7871:
--
Labels: patch  (was: )

> Batch file for Windows is missing from source distribution (qpid-tools 1.36.0)
> --
>
> Key: QPID-7871
> URL: https://issues.apache.org/jira/browse/QPID-7871
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Affects Versions: qpid-cpp-1.36.0
>Reporter: Irina Boverman
>Assignee: Irina Boverman
>  Labels: patch
> Fix For: qpid-cpp-1.37.0
>
> Attachments: QPID-7871-Added-.bat-files.patch
>
>
> Reported here:
> http://qpid.2158936.n2.nabble.com/qpid-tools-on-PyPi-tc7665012.html#none



--
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] [Updated] (QPID-7871) Batch file for Windows is missing from source distribution (qpid-tools 1.36.0)

2017-07-26 Thread Irina Boverman (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Irina Boverman updated QPID-7871:
-
Flags: Patch

> Batch file for Windows is missing from source distribution (qpid-tools 1.36.0)
> --
>
> Key: QPID-7871
> URL: https://issues.apache.org/jira/browse/QPID-7871
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Affects Versions: qpid-cpp-1.36.0
>Reporter: Irina Boverman
>Assignee: Irina Boverman
> Fix For: qpid-cpp-1.37.0
>
> Attachments: QPID-7871-Added-.bat-files.patch
>
>
> Reported here:
> http://qpid.2158936.n2.nabble.com/qpid-tools-on-PyPi-tc7665012.html#none



--
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-7871) Batch file for Windows is missing from source distribution (qpid-tools 1.36.0)

2017-07-26 Thread Irina Boverman (JIRA) 

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

Irina Boverman commented on QPID-7871:
--

Attached a patch.

> Batch file for Windows is missing from source distribution (qpid-tools 1.36.0)
> --
>
> Key: QPID-7871
> URL: https://issues.apache.org/jira/browse/QPID-7871
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Affects Versions: qpid-cpp-1.36.0
>Reporter: Irina Boverman
>Assignee: Irina Boverman
> Fix For: qpid-cpp-1.37.0
>
> Attachments: QPID-7871-Added-.bat-files.patch
>
>
> Reported here:
> http://qpid.2158936.n2.nabble.com/qpid-tools-on-PyPi-tc7665012.html#none



--
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] [Updated] (QPID-7871) Batch file for Windows is missing from source distribution (qpid-tools 1.36.0)

2017-07-26 Thread Irina Boverman (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Irina Boverman updated QPID-7871:
-
Attachment: QPID-7871-Added-.bat-files.patch

> Batch file for Windows is missing from source distribution (qpid-tools 1.36.0)
> --
>
> Key: QPID-7871
> URL: https://issues.apache.org/jira/browse/QPID-7871
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Affects Versions: qpid-cpp-1.36.0
>Reporter: Irina Boverman
>Assignee: Irina Boverman
> Fix For: qpid-cpp-1.37.0
>
> Attachments: QPID-7871-Added-.bat-files.patch
>
>
> Reported here:
> http://qpid.2158936.n2.nabble.com/qpid-tools-on-PyPi-tc7665012.html#none



--
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] [Updated] (QPID-7871) Batch file for Windows is missing from source distribution (qpid-tools 1.36.0)

2017-07-26 Thread Irina Boverman (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Irina Boverman updated QPID-7871:
-
Summary: Batch file for Windows is missing from source distribution 
(qpid-tools 1.36.0)  (was: CLONE - Batch file for Windows is missing from 
source distribution)

> Batch file for Windows is missing from source distribution (qpid-tools 1.36.0)
> --
>
> Key: QPID-7871
> URL: https://issues.apache.org/jira/browse/QPID-7871
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Affects Versions: qpid-cpp-1.36.0
>Reporter: Irina Boverman
>Assignee: Irina Boverman
> Fix For: qpid-cpp-1.37.0
>
>
> Reported here:
> http://qpid.2158936.n2.nabble.com/qpid-tools-on-PyPi-tc7665012.html#none



--
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] [Updated] (QPID-7871) CLONE - Batch file for Windows is missing from source distribution

2017-07-26 Thread Irina Boverman (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Irina Boverman updated QPID-7871:
-
Affects Version/s: (was: qpid-python-1.36.0)
   qpid-cpp-1.36.0
Fix Version/s: (was: qpid-python-1.37.0)
   qpid-cpp-1.37.0
  Description: 
Reported here:
http://qpid.2158936.n2.nabble.com/qpid-tools-on-PyPi-tc7665012.html#none

  was:
Reported on the user list:
http://qpid.2158936.n2.nabble.com/qpid-python-test-bat-does-not-exist-tt7664284.html


> CLONE - Batch file for Windows is missing from source distribution
> --
>
> Key: QPID-7871
> URL: https://issues.apache.org/jira/browse/QPID-7871
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Affects Versions: qpid-cpp-1.36.0
>Reporter: Irina Boverman
>Assignee: Irina Boverman
> Fix For: qpid-cpp-1.37.0
>
>
> Reported here:
> http://qpid.2158936.n2.nabble.com/qpid-tools-on-PyPi-tc7665012.html#none



--
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] [Created] (QPID-7871) CLONE - Batch file for Windows is missing from source distribution

2017-07-26 Thread Irina Boverman (JIRA) 
Irina Boverman created QPID-7871:


 Summary: CLONE - Batch file for Windows is missing from source 
distribution
 Key: QPID-7871
 URL: https://issues.apache.org/jira/browse/QPID-7871
 Project: Qpid
  Issue Type: Bug
  Components: Python Client
Affects Versions: qpid-python-1.36.0
Reporter: Irina Boverman
Assignee: Irina Boverman
 Fix For: qpid-python-1.37.0


Reported on the user list:
http://qpid.2158936.n2.nabble.com/qpid-python-test-bat-does-not-exist-tt7664284.html



--
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] (PROTON-1525) enable configuring the initial remote max frame size limit

2017-07-26 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101969#comment-16101969
 ] 

ASF subversion and git services commented on PROTON-1525:
-

Commit d6181e334193c4383a7deee8e264ceae0ecddfa7 in qpid-proton-j's branch 
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton-j.git;h=d6181e3 ]

PROTON-1525: enable configuring the initial remote max frame size limit to 
permit larger sasl frames


> enable configuring the initial remote max frame size limit
> --
>
> Key: PROTON-1525
> URL: https://issues.apache.org/jira/browse/PROTON-1525
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: proton-j-0.20.0
>
>
> Whilst trying to add support for the GSSAPI mechanism for QPIDJMS-303, Gary 
> ran into an issue whereby the size of initial response lead to a sasl-init 
> frame being emitted which fell foul of frame size enforcement at the 
> receiver. Per the discussion on the mailing lists \[1\], this JIRA will add 
> support for configurably relaxing this limit in scenerios it is known a 
> larger value is necessary to allow an existing mechanism to function, by 
> enabling control over the initial value of the transports remote max frame 
> size before an Open is received.
> \[1\] 
> https://lists.apache.org/thread.html/f5635f366dfcc757933537b472ee6b052f3a23dea9fdcc5f104983da@%3Cdev.qpid.apache.org%3E



--
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] [Created] (PROTON-1525) enable configuring the initial remote max frame size limit

2017-07-26 Thread Robbie Gemmell (JIRA) 
Robbie Gemmell created PROTON-1525:
--

 Summary: enable configuring the initial remote max frame size limit
 Key: PROTON-1525
 URL: https://issues.apache.org/jira/browse/PROTON-1525
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-j
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
 Fix For: proton-j-0.20.0


Whilst trying to add support for the GSSAPI mechanism for QPIDJMS-303, Gary ran 
into an issue whereby the size of initial response lead to a sasl-init frame 
being emitted which fell foul of frame size enforcement at the receiver. Per 
the discussion on the mailing lists \[1\], this JIRA will add support for 
configurably relaxing this limit in scenerios it is known a larger value is 
necessary to allow an existing mechanism to function, by enabling control over 
the initial value of the transports remote max frame size before an Open is 
received.

\[1\] 
https://lists.apache.org/thread.html/f5635f366dfcc757933537b472ee6b052f3a23dea9fdcc5f104983da@%3Cdev.qpid.apache.org%3E



--
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] (PROTON-1278) [Proton-c] Closing connection in proton::handler puts connection in TIME_WAIT state

2017-07-26 Thread Justin Ross (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101884#comment-16101884
 ] 

Justin Ross commented on PROTON-1278:
-

[~adelbout...@live.com], thanks!

> [Proton-c] Closing connection in proton::handler puts connection in TIME_WAIT 
> state
> ---
>
> Key: PROTON-1278
> URL: https://issues.apache.org/jira/browse/PROTON-1278
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding, proton-c
>Affects Versions: 0.12.2
>Reporter: Adel Boutros
>Assignee: Alan Conway
>  Labels: reproducer
> Fix For: proton-c-0.18.0
>
> Attachments: ConnectionTimeWaitState.cpp, Wireshark output.png
>
>
> You can check 
> [Nabble|http://qpid.2158936.n2.nabble.com/Java-Broker-6-0-1-AMQP-random-errors-when-sending-messages-using-Proton-c-0-12-2-td7648822.html]
>   for more details.



--
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

[GitHub] qpid-proton pull request #113: [Solaris] fix build with gcc-4.9

2017-07-26 Thread matlo607 
GitHub user matlo607 opened a pull request:

https://github.com/apache/qpid-proton/pull/113

[Solaris] fix build with gcc-4.9



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/matlo607/qpid-proton fix-build-gcc49-solaris

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-proton/pull/113.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #113


commit 6d587f2c3e6bd7f27d16983f288c7e23638c9a19
Author: Matthieu Longo 
Date:   2017-07-24T13:04:07Z

fix build errors triggered by -Werror=parentheses

commit c7b426439000c989462299f4deade938256836c1
Author: Matthieu Longo 
Date:   2017-07-24T13:17:38Z

[solaris] change linker's flags since GCC uses Solaris's default linker

commit ea8fbf89872a1642108314af1db89a707c6a7ef2
Author: Matthieu Longo 
Date:   2017-07-26T12:58:53Z

[solaris] add extra linker flag -lsocket

commit 4227f197f21d1a633c1bda132ff9084d99cd0e10
Author: Matthieu Longo 
Date:   2017-07-26T14:38:47Z

[solaris] fix -Werror=implicit-function-declaration on getopt()




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: qpid-tools on PyPi

2017-07-26 Thread Irina Boverman 
Hi Lorenz,
I am maintaining qpid-tools in PyPi and will post revised version which
will include .bat files later today.
Regards, Irina.

On Fri, Jul 21, 2017 at 9:44 AM, Lorenz Quack 
wrote:

> Hello list,
>
> does anyone know who is responsible for the qpid-tools on PyPi [1]?
>
> It says the author is Apache Qpid but I cannot find a reference to
> it on our webpage and worse I cannot find the sources.
>
> I have a report that it does not install on windows with pip (it
> complains about qpid-config.bat not being present).
>
> Kind regards,
> Lorenz
>
>
> [1] https://pypi.python.org/pypi/qpid-tools
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>

[jira] [Commented] (PROTON-1278) [Proton-c] Closing connection in proton::handler puts connection in TIME_WAIT state

2017-07-26 Thread Adel Boutros (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101706#comment-16101706
 ] 

Adel Boutros commented on PROTON-1278:
--

[~jr...@redhat.com] We have planned to update our proton version to use 0.17.0 
and try Libuv to be able to use the proactor code for event injection.
We had implemented a workaround to avoid the issue mentioned in this Jira 
issue. So I think we can safely close cancel it

> [Proton-c] Closing connection in proton::handler puts connection in TIME_WAIT 
> state
> ---
>
> Key: PROTON-1278
> URL: https://issues.apache.org/jira/browse/PROTON-1278
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding, proton-c
>Affects Versions: 0.12.2
>Reporter: Adel Boutros
>Assignee: Alan Conway
>  Labels: reproducer
> Fix For: proton-c-0.18.0
>
> Attachments: ConnectionTimeWaitState.cpp, Wireshark output.png
>
>
> You can check 
> [Nabble|http://qpid.2158936.n2.nabble.com/Java-Broker-6-0-1-AMQP-random-errors-when-sending-messages-using-Proton-c-0-12-2-td7648822.html]
>   for more details.



--
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

Re: SASL GSSAPI and MIN-MAX-FRAME-SIZE

2017-07-26 Thread Rob Godfrey 
On 26 July 2017 at 15:38, Robbie Gemmell  wrote:

> On 26 July 2017 at 14:09, Rob Godfrey  wrote:
> > On 26 July 2017 at 14:43, Robbie Gemmell 
> wrote:
> >
> >> That essentially summarises some discussion I had with others on this
> >> elsewhere late yesterday and was planning to see what you and others
> >> thought about it after having a look at the impls.
> >>
> >> I agree that making a custom mechanism for fragmenting an existing
> >> mechanisms content is ugly and probably of little value in the end
> >> since you would still need to handle the whole as you say. If the
> >> regular mechanism name was offered and it needs >512 byte in a given
> >> situation then it obviously wouldnt work if you enforce that limit..so
> >> either you couldnt expect it to work anyway, in which case why offer
> >> it, or presumably wouldnt enforce the limit. If servers dont offer
> >> such mechanism or clients dont select them, which many wont in this
> >> case, there isn't an issue for them.
> >>
> >> To allow proceeding despite the size, we would need to add a toggle to
> >> proton-j to control what it will allow to be received for sasl frames,
> >> or adjust the default size it will allow, or both. The simplest thing
> >> toggle wise would look to be making the existing transport 'remote max
> >> frame size' overridable until set by the Open frame arriving and use
> >> it to govern this behaviour.
> >>
> >
> > That (configurable initial maximum) sounds sensible to me.  Ultimately
> > outside of the (in-discussion) CBS mechanism neither side really has much
> > influence over the size of the data being exchanged.  Out of interest, on
> > the sending size does proton already just send large SASL frames if you
> > supply it with > 512 bytes of data, or does it error?
> >
> > -- Rob
> >
>
> It does just send them, yes.
>

Ah - it's following the the exact opposite of the robustness principle
then, nice :)

-- Rob


>
> >
> >>
> >> Robbie
> >>
> >> On 26 July 2017 at 09:34, Rob Godfrey  wrote:
> >> > *sigh* I always thought 512 was a bit on the low side for this limit
> :-(
> >> >
> >> > For background the original intent of setting MIN-MAX-FRAME-SIZE at
> 512
> >> > bytes was to allow AMQP to be used on devices with very limited
> >> resources.
> >> > Logic(?) then dictated that all frames exchanged prior to a new max
> frame
> >> > size being agreed need to fit within the known minimum frame size
> limit.
> >> > In retrospect for SASL this was a mistake, as normally you don't
> really
> >> > have any choice ab out how big your sasl frames are going to be (the
> size
> >> > will be determined by the requirements of the mechanism).  If (say) we
> >> > allowed proton to be more relaxed in the frame sizes it allows (we'd
> >> still
> >> > want some limit to prevent DoS style attacks) then the worst that
> happens
> >> > (I think) is that SASL mechanisms that require larger frames will not
> >> work
> >> > against implementations which enforce the 512 byte limit... but then
> such
> >> > implementations can't realistically be supporting mechanisms which
> >> require
> >> > larger exchanges (such as GSSAPI/Kerberos).  I don't really see the
> value
> >> > in inventing a new SASL mechanism for this (allowing fragmentation of
> the
> >> > responses) as in reality this wouldn't help systems with limited
> >> resources
> >> > implement the mechanism (they'll still need to assemble the whole
> >> response
> >> > at some point I imagine).  Techniacally this will be spec violating,
> but
> >> > OTOH without violating the spec you can't implement the mechanism, so
> if
> >> > you offer the mechanism then you are implicitly saying "I'm not going
> to
> >> > enforce this rule".
> >> >
> >> > -- Rob
> >> >
> >> > On 25 July 2017 at 18:02, Gary Tully  wrote:
> >> >
> >> >> Hi,
> >> >> I have been working through adding SASL GSSAPI (Kerberos) support to
> the
> >> >> qpid-jms-client[1] and have hit a limit in proton-j
> >> >>
> >> >> The initial response in the SASL_Init frame can be > 512 which breaks
> >> the
> >> >> max frame size limitation as frame size negotiation has not completed
> >> yet.
> >> >> Proton-j will allow the frame to be written but the parse at the
> other
> >> end
> >> >> identifies the size exceeding the limit and errors out.
> >> >>
> >> >> I see in the AMQP Claims Based Security draft there is some work to
> >> >> describe how to SASL within that limitation in the context of a new
> >> >> mechanism.
> >> >>
> >> >> Is it reasonable to relax the check via config to allow the existing
> >> gssapi
> >> >> mechanism to work.
> >> >>
> >> >> Of the top of your head, what does proton-c do, maybe it never sends
> an
> >> >> initial response in the sasl_init?
> >> >>
> >> >> thanks in advance for any read of this :-)
> >> >>
> >> >> gary.
> >> >>
> >> >> [1]

Re: SASL GSSAPI and MIN-MAX-FRAME-SIZE

2017-07-26 Thread Robbie Gemmell 
On 26 July 2017 at 14:09, Rob Godfrey  wrote:
> On 26 July 2017 at 14:43, Robbie Gemmell  wrote:
>
>> That essentially summarises some discussion I had with others on this
>> elsewhere late yesterday and was planning to see what you and others
>> thought about it after having a look at the impls.
>>
>> I agree that making a custom mechanism for fragmenting an existing
>> mechanisms content is ugly and probably of little value in the end
>> since you would still need to handle the whole as you say. If the
>> regular mechanism name was offered and it needs >512 byte in a given
>> situation then it obviously wouldnt work if you enforce that limit..so
>> either you couldnt expect it to work anyway, in which case why offer
>> it, or presumably wouldnt enforce the limit. If servers dont offer
>> such mechanism or clients dont select them, which many wont in this
>> case, there isn't an issue for them.
>>
>> To allow proceeding despite the size, we would need to add a toggle to
>> proton-j to control what it will allow to be received for sasl frames,
>> or adjust the default size it will allow, or both. The simplest thing
>> toggle wise would look to be making the existing transport 'remote max
>> frame size' overridable until set by the Open frame arriving and use
>> it to govern this behaviour.
>>
>
> That (configurable initial maximum) sounds sensible to me.  Ultimately
> outside of the (in-discussion) CBS mechanism neither side really has much
> influence over the size of the data being exchanged.  Out of interest, on
> the sending size does proton already just send large SASL frames if you
> supply it with > 512 bytes of data, or does it error?
>
> -- Rob
>

It does just send them, yes.

>
>>
>> Robbie
>>
>> On 26 July 2017 at 09:34, Rob Godfrey  wrote:
>> > *sigh* I always thought 512 was a bit on the low side for this limit :-(
>> >
>> > For background the original intent of setting MIN-MAX-FRAME-SIZE at 512
>> > bytes was to allow AMQP to be used on devices with very limited
>> resources.
>> > Logic(?) then dictated that all frames exchanged prior to a new max frame
>> > size being agreed need to fit within the known minimum frame size limit.
>> > In retrospect for SASL this was a mistake, as normally you don't really
>> > have any choice ab out how big your sasl frames are going to be (the size
>> > will be determined by the requirements of the mechanism).  If (say) we
>> > allowed proton to be more relaxed in the frame sizes it allows (we'd
>> still
>> > want some limit to prevent DoS style attacks) then the worst that happens
>> > (I think) is that SASL mechanisms that require larger frames will not
>> work
>> > against implementations which enforce the 512 byte limit... but then such
>> > implementations can't realistically be supporting mechanisms which
>> require
>> > larger exchanges (such as GSSAPI/Kerberos).  I don't really see the value
>> > in inventing a new SASL mechanism for this (allowing fragmentation of the
>> > responses) as in reality this wouldn't help systems with limited
>> resources
>> > implement the mechanism (they'll still need to assemble the whole
>> response
>> > at some point I imagine).  Techniacally this will be spec violating, but
>> > OTOH without violating the spec you can't implement the mechanism, so if
>> > you offer the mechanism then you are implicitly saying "I'm not going to
>> > enforce this rule".
>> >
>> > -- Rob
>> >
>> > On 25 July 2017 at 18:02, Gary Tully  wrote:
>> >
>> >> Hi,
>> >> I have been working through adding SASL GSSAPI (Kerberos) support to the
>> >> qpid-jms-client[1] and have hit a limit in proton-j
>> >>
>> >> The initial response in the SASL_Init frame can be > 512 which breaks
>> the
>> >> max frame size limitation as frame size negotiation has not completed
>> yet.
>> >> Proton-j will allow the frame to be written but the parse at the other
>> end
>> >> identifies the size exceeding the limit and errors out.
>> >>
>> >> I see in the AMQP Claims Based Security draft there is some work to
>> >> describe how to SASL within that limitation in the context of a new
>> >> mechanism.
>> >>
>> >> Is it reasonable to relax the check via config to allow the existing
>> gssapi
>> >> mechanism to work.
>> >>
>> >> Of the top of your head, what does proton-c do, maybe it never sends an
>> >> initial response in the sasl_init?
>> >>
>> >> thanks in advance for any read of this :-)
>> >>
>> >> gary.
>> >>
>> >> [1] https://issues.apache.org/jira/browse/QPIDJMS-303
>> >>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: dev-h...@qpid.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: SASL GSSAPI and MIN-MAX-FRAME-SIZE

2017-07-26 Thread Rob Godfrey 
On 26 July 2017 at 14:43, Robbie Gemmell  wrote:

> That essentially summarises some discussion I had with others on this
> elsewhere late yesterday and was planning to see what you and others
> thought about it after having a look at the impls.
>
> I agree that making a custom mechanism for fragmenting an existing
> mechanisms content is ugly and probably of little value in the end
> since you would still need to handle the whole as you say. If the
> regular mechanism name was offered and it needs >512 byte in a given
> situation then it obviously wouldnt work if you enforce that limit..so
> either you couldnt expect it to work anyway, in which case why offer
> it, or presumably wouldnt enforce the limit. If servers dont offer
> such mechanism or clients dont select them, which many wont in this
> case, there isn't an issue for them.
>
> To allow proceeding despite the size, we would need to add a toggle to
> proton-j to control what it will allow to be received for sasl frames,
> or adjust the default size it will allow, or both. The simplest thing
> toggle wise would look to be making the existing transport 'remote max
> frame size' overridable until set by the Open frame arriving and use
> it to govern this behaviour.
>

That (configurable initial maximum) sounds sensible to me.  Ultimately
outside of the (in-discussion) CBS mechanism neither side really has much
influence over the size of the data being exchanged.  Out of interest, on
the sending size does proton already just send large SASL frames if you
supply it with > 512 bytes of data, or does it error?

-- Rob


>
> Robbie
>
> On 26 July 2017 at 09:34, Rob Godfrey  wrote:
> > *sigh* I always thought 512 was a bit on the low side for this limit :-(
> >
> > For background the original intent of setting MIN-MAX-FRAME-SIZE at 512
> > bytes was to allow AMQP to be used on devices with very limited
> resources.
> > Logic(?) then dictated that all frames exchanged prior to a new max frame
> > size being agreed need to fit within the known minimum frame size limit.
> > In retrospect for SASL this was a mistake, as normally you don't really
> > have any choice ab out how big your sasl frames are going to be (the size
> > will be determined by the requirements of the mechanism).  If (say) we
> > allowed proton to be more relaxed in the frame sizes it allows (we'd
> still
> > want some limit to prevent DoS style attacks) then the worst that happens
> > (I think) is that SASL mechanisms that require larger frames will not
> work
> > against implementations which enforce the 512 byte limit... but then such
> > implementations can't realistically be supporting mechanisms which
> require
> > larger exchanges (such as GSSAPI/Kerberos).  I don't really see the value
> > in inventing a new SASL mechanism for this (allowing fragmentation of the
> > responses) as in reality this wouldn't help systems with limited
> resources
> > implement the mechanism (they'll still need to assemble the whole
> response
> > at some point I imagine).  Techniacally this will be spec violating, but
> > OTOH without violating the spec you can't implement the mechanism, so if
> > you offer the mechanism then you are implicitly saying "I'm not going to
> > enforce this rule".
> >
> > -- Rob
> >
> > On 25 July 2017 at 18:02, Gary Tully  wrote:
> >
> >> Hi,
> >> I have been working through adding SASL GSSAPI (Kerberos) support to the
> >> qpid-jms-client[1] and have hit a limit in proton-j
> >>
> >> The initial response in the SASL_Init frame can be > 512 which breaks
> the
> >> max frame size limitation as frame size negotiation has not completed
> yet.
> >> Proton-j will allow the frame to be written but the parse at the other
> end
> >> identifies the size exceeding the limit and errors out.
> >>
> >> I see in the AMQP Claims Based Security draft there is some work to
> >> describe how to SASL within that limitation in the context of a new
> >> mechanism.
> >>
> >> Is it reasonable to relax the check via config to allow the existing
> gssapi
> >> mechanism to work.
> >>
> >> Of the top of your head, what does proton-c do, maybe it never sends an
> >> initial response in the sasl_init?
> >>
> >> thanks in advance for any read of this :-)
> >>
> >> gary.
> >>
> >> [1] https://issues.apache.org/jira/browse/QPIDJMS-303
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>

Re: SASL GSSAPI and MIN-MAX-FRAME-SIZE

2017-07-26 Thread Robbie Gemmell 
That essentially summarises some discussion I had with others on this
elsewhere late yesterday and was planning to see what you and others
thought about it after having a look at the impls.

I agree that making a custom mechanism for fragmenting an existing
mechanisms content is ugly and probably of little value in the end
since you would still need to handle the whole as you say. If the
regular mechanism name was offered and it needs >512 byte in a given
situation then it obviously wouldnt work if you enforce that limit..so
either you couldnt expect it to work anyway, in which case why offer
it, or presumably wouldnt enforce the limit. If servers dont offer
such mechanism or clients dont select them, which many wont in this
case, there isn't an issue for them.

To allow proceeding despite the size, we would need to add a toggle to
proton-j to control what it will allow to be received for sasl frames,
or adjust the default size it will allow, or both. The simplest thing
toggle wise would look to be making the existing transport 'remote max
frame size' overridable until set by the Open frame arriving and use
it to govern this behaviour.

Robbie

On 26 July 2017 at 09:34, Rob Godfrey  wrote:
> *sigh* I always thought 512 was a bit on the low side for this limit :-(
>
> For background the original intent of setting MIN-MAX-FRAME-SIZE at 512
> bytes was to allow AMQP to be used on devices with very limited resources.
> Logic(?) then dictated that all frames exchanged prior to a new max frame
> size being agreed need to fit within the known minimum frame size limit.
> In retrospect for SASL this was a mistake, as normally you don't really
> have any choice ab out how big your sasl frames are going to be (the size
> will be determined by the requirements of the mechanism).  If (say) we
> allowed proton to be more relaxed in the frame sizes it allows (we'd still
> want some limit to prevent DoS style attacks) then the worst that happens
> (I think) is that SASL mechanisms that require larger frames will not work
> against implementations which enforce the 512 byte limit... but then such
> implementations can't realistically be supporting mechanisms which require
> larger exchanges (such as GSSAPI/Kerberos).  I don't really see the value
> in inventing a new SASL mechanism for this (allowing fragmentation of the
> responses) as in reality this wouldn't help systems with limited resources
> implement the mechanism (they'll still need to assemble the whole response
> at some point I imagine).  Techniacally this will be spec violating, but
> OTOH without violating the spec you can't implement the mechanism, so if
> you offer the mechanism then you are implicitly saying "I'm not going to
> enforce this rule".
>
> -- Rob
>
> On 25 July 2017 at 18:02, Gary Tully  wrote:
>
>> Hi,
>> I have been working through adding SASL GSSAPI (Kerberos) support to the
>> qpid-jms-client[1] and have hit a limit in proton-j
>>
>> The initial response in the SASL_Init frame can be > 512 which breaks the
>> max frame size limitation as frame size negotiation has not completed yet.
>> Proton-j will allow the frame to be written but the parse at the other end
>> identifies the size exceeding the limit and errors out.
>>
>> I see in the AMQP Claims Based Security draft there is some work to
>> describe how to SASL within that limitation in the context of a new
>> mechanism.
>>
>> Is it reasonable to relax the check via config to allow the existing gssapi
>> mechanism to work.
>>
>> Of the top of your head, what does proton-c do, maybe it never sends an
>> initial response in the sasl_init?
>>
>> thanks in advance for any read of this :-)
>>
>> gary.
>>
>> [1] https://issues.apache.org/jira/browse/QPIDJMS-303
>>

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-proton issue #112: fix paths to test binaries

2017-07-26 Thread matlo607 
Github user matlo607 commented on the issue:

https://github.com/apache/qpid-proton/pull/112
  
@astitcher 
Please could you give me some hints to fix the build on Windows ?
I don't have a clue and a Windows machine too.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
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)

2017-07-26 Thread ASF subversion and git services (JIRA) 

[ 
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

Re: SASL GSSAPI and MIN-MAX-FRAME-SIZE

2017-07-26 Thread Rob Godfrey 
*sigh* I always thought 512 was a bit on the low side for this limit :-(

For background the original intent of setting MIN-MAX-FRAME-SIZE at 512
bytes was to allow AMQP to be used on devices with very limited resources.
Logic(?) then dictated that all frames exchanged prior to a new max frame
size being agreed need to fit within the known minimum frame size limit.
In retrospect for SASL this was a mistake, as normally you don't really
have any choice ab out how big your sasl frames are going to be (the size
will be determined by the requirements of the mechanism).  If (say) we
allowed proton to be more relaxed in the frame sizes it allows (we'd still
want some limit to prevent DoS style attacks) then the worst that happens
(I think) is that SASL mechanisms that require larger frames will not work
against implementations which enforce the 512 byte limit... but then such
implementations can't realistically be supporting mechanisms which require
larger exchanges (such as GSSAPI/Kerberos).  I don't really see the value
in inventing a new SASL mechanism for this (allowing fragmentation of the
responses) as in reality this wouldn't help systems with limited resources
implement the mechanism (they'll still need to assemble the whole response
at some point I imagine).  Techniacally this will be spec violating, but
OTOH without violating the spec you can't implement the mechanism, so if
you offer the mechanism then you are implicitly saying "I'm not going to
enforce this rule".

-- Rob

On 25 July 2017 at 18:02, Gary Tully  wrote:

> Hi,
> I have been working through adding SASL GSSAPI (Kerberos) support to the
> qpid-jms-client[1] and have hit a limit in proton-j
>
> The initial response in the SASL_Init frame can be > 512 which breaks the
> max frame size limitation as frame size negotiation has not completed yet.
> Proton-j will allow the frame to be written but the parse at the other end
> identifies the size exceeding the limit and errors out.
>
> I see in the AMQP Claims Based Security draft there is some work to
> describe how to SASL within that limitation in the context of a new
> mechanism.
>
> Is it reasonable to relax the check via config to allow the existing gssapi
> mechanism to work.
>
> Of the top of your head, what does proton-c do, maybe it never sends an
> initial response in the sasl_init?
>
> thanks in advance for any read of this :-)
>
> gary.
>
> [1] https://issues.apache.org/jira/browse/QPIDJMS-303
>

[jira] [Commented] (QPID-7870) [Java Broker] Remove support for the x-opt-jms-type message annotation

2017-07-26 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on QPID-7870:
---

Commit 6b120b94a0f7ee2ca47616569b1140afa819e734 in qpid-broker-j's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=6b120b9 ]

QPID-7870: Exclude org.objectweb.jtests.jms.conform.selector.SelectorTest from 
Joram test suite for the POC client only


> [Java Broker] Remove support for the x-opt-jms-type message annotation
> --
>
> Key: QPID-7870
> URL: https://issues.apache.org/jira/browse/QPID-7870
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The {{x-opt-jms-type}} message annotation was used by the proof of concept 
> amqp-1-0-client-jms (last released as part of 0.32 and no longer maintained), 
> but is not part of the standard emerging from the AMQP / JMS Bindmap process. 
>  Support for {{x-opt-jms-type}} should be removed from the Broker.



--
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)

2017-07-26 Thread ASF subversion and git services (JIRA) 

[ 
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)

2017-07-26 Thread ASF subversion and git services (JIRA) 

[ 
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