[jira] [Created] (PROTON-894) ErrorCondition 'info' map should be typed to enforce required use of Symbol keys
Robbie Gemmell created PROTON-894: - Summary: ErrorCondition 'info' map should be typed to enforce required use of Symbol keys Key: PROTON-894 URL: https://issues.apache.org/jira/browse/PROTON-894 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9, 0.8, 0.7, 0.6, 0.5, 0.4, 0.3, 0.2, 0.1, 0.9.1 Reporter: Robbie Gemmell The 'info' field of amqp-error [1] condition is of type 'fields' [2], a Symbol keyed map. The 'info' map in the ErrorCondition object should thus be typed for Symbol keys, whereas currently it is not typed at all implying use of any type is permissable, e.g. the common use of String keys. [1] http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-error [2] http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-fields -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-893) Calling the session.close() on non-active session causes client seqfault
[ https://issues.apache.org/jira/browse/PROTON-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr Matousek updated PROTON-893: - Attachment: stacktrace.txt Calling the session.close() on non-active session causes client seqfault Key: PROTON-893 URL: https://issues.apache.org/jira/browse/PROTON-893 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9.1 Environment: packages: qpid-proton-c-0.9-3 qpid-proton-c-devel-0.9-3 python-qpid-proton-0.9-3 Reporter: Petr Matousek Priority: Minor Attachments: session_close_con.py, session_close_ssn.py, stacktrace.txt Calling the session.close() on non-active session causes client seqfault (see the attached reproducer session_close_con.py). Moreover calling connection.session().close() causes client seqfault even if the session shall be in active state (see the attached reproducer session_close_ssn.py). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-893) Calling the session.close() on non-active session causes client seqfault
[ https://issues.apache.org/jira/browse/PROTON-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr Matousek updated PROTON-893: - Attachment: session_close_ssn.py Calling the session.close() on non-active session causes client seqfault Key: PROTON-893 URL: https://issues.apache.org/jira/browse/PROTON-893 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9.1 Environment: packages: qpid-proton-c-0.9-3 qpid-proton-c-devel-0.9-3 python-qpid-proton-0.9-3 Reporter: Petr Matousek Priority: Minor Attachments: session_close_con.py, session_close_ssn.py, stacktrace.txt Calling the session.close() on non-active session causes client seqfault (see the attached reproducer session_close_con.py). Moreover calling connection.session().close() causes client seqfault even if the session shall be in active state (see the attached reproducer session_close_ssn.py). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-893) Calling the session.close() on non-active session causes client seqfault
Petr Matousek created PROTON-893: Summary: Calling the session.close() on non-active session causes client seqfault Key: PROTON-893 URL: https://issues.apache.org/jira/browse/PROTON-893 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9.1 Environment: packages: qpid-proton-c-0.9-3 qpid-proton-c-devel-0.9-3 python-qpid-proton-0.9-3 Reporter: Petr Matousek Priority: Minor Calling the session.close() on non-active session causes client seqfault (see the attached reproducer session_close_con.py). Moreover calling connection.session().close() causes client seqfault even if the session shall be in active state (see the attached reproducer session_close_ssn.py). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-895) Rely on python to build the downloaded tarball
[ https://issues.apache.org/jira/browse/PROTON-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-895: - Assignee: Ken Giusti Rely on python to build the downloaded tarball -- Key: PROTON-895 URL: https://issues.apache.org/jira/browse/PROTON-895 Project: Qpid Proton Issue Type: Bug Reporter: Flavio Percoco Assignee: Ken Giusti Attachments: 0001-Rely-on-python-to-build-downloaded-tarball.patch Recently, a patch that made python-qpid-proton's setup.py download proton-c and build it whenever it's not found in the system. The patch relied on cmake to build the library as everyone would do when building proton-c. While that works, it's not the right, most pythonic, reliable way to do it. Some reasons why it's not a good thing: 1. It might overwrite a system qpid install if there's one and if the python-qpid-proton library is being installed in the system 2. It requires users - including CI systems, etc - to have cmake installed. 3. It does everything from outside the Python mechanism. The patch proposed in this bug changes the current behavior in favor of using Python's build extensions to compile the library. The patch follows the same steps as you'd do with cmake and it does it *just* for the downloaded tarball. If there's an installed proton-c library, there's nothing to do. If you're building it using cmake from a proton-c dir, it'll keep using cmake normally. The built library doesn't have the same name as the global one and it's installed along with the python binding instead of installing header files and the library itself system wide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-895) Rely on python to build the downloaded tarball
Flavio Percoco created PROTON-895: - Summary: Rely on python to build the downloaded tarball Key: PROTON-895 URL: https://issues.apache.org/jira/browse/PROTON-895 Project: Qpid Proton Issue Type: Bug Reporter: Flavio Percoco Recently, a patch that made python-qpid-proton's setup.py download proton-c and build it whenever it's not found in the system. The patch relied on cmake to build the library as everyone would do when building proton-c. While that works, it's not the right, most pythonic, reliable way to do it. Some reasons why it's not a good thing: 1. It might overwrite a system qpid install if there's one and if the python-qpid-proton library is being installed in the system 2. It requires users - including CI systems, etc - to have cmake installed. 3. It does everything from outside the Python mechanism. The patch proposed in this bug changes the current behavior in favor of using Python's build extensions to compile the library. The patch follows the same steps as you'd do with cmake and it does it *just* for the downloaded tarball. If there's an installed proton-c library, there's nothing to do. If you're building it using cmake from a proton-c dir, it'll keep using cmake normally. The built library doesn't have the same name as the global one and it's installed along with the python binding instead of installing header files and the library itself system wide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-895) Rely on python to build the downloaded tarball
[ https://issues.apache.org/jira/browse/PROTON-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Percoco updated PROTON-895: -- Attachment: 0001-Rely-on-python-to-build-downloaded-tarball.patch Rely on python to build the downloaded tarball -- Key: PROTON-895 URL: https://issues.apache.org/jira/browse/PROTON-895 Project: Qpid Proton Issue Type: Bug Reporter: Flavio Percoco Attachments: 0001-Rely-on-python-to-build-downloaded-tarball.patch Recently, a patch that made python-qpid-proton's setup.py download proton-c and build it whenever it's not found in the system. The patch relied on cmake to build the library as everyone would do when building proton-c. While that works, it's not the right, most pythonic, reliable way to do it. Some reasons why it's not a good thing: 1. It might overwrite a system qpid install if there's one and if the python-qpid-proton library is being installed in the system 2. It requires users - including CI systems, etc - to have cmake installed. 3. It does everything from outside the Python mechanism. The patch proposed in this bug changes the current behavior in favor of using Python's build extensions to compile the library. The patch follows the same steps as you'd do with cmake and it does it *just* for the downloaded tarball. If there's an installed proton-c library, there's nothing to do. If you're building it using cmake from a proton-c dir, it'll keep using cmake normally. The built library doesn't have the same name as the global one and it's installed along with the python binding instead of installing header files and the library itself system wide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-895) Rely on python to build the downloaded tarball
[ https://issues.apache.org/jira/browse/PROTON-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Percoco updated PROTON-895: -- Attachment: (was: 0001-Rely-on-python-to-build-downloaded-tarball.patch) Rely on python to build the downloaded tarball -- Key: PROTON-895 URL: https://issues.apache.org/jira/browse/PROTON-895 Project: Qpid Proton Issue Type: Bug Reporter: Flavio Percoco Assignee: Ken Giusti Attachments: 0001-Rely-on-python-to-build-downloaded-tarball.patch Recently, a patch that made python-qpid-proton's setup.py download proton-c and build it whenever it's not found in the system. The patch relied on cmake to build the library as everyone would do when building proton-c. While that works, it's not the right, most pythonic, reliable way to do it. Some reasons why it's not a good thing: 1. It might overwrite a system qpid install if there's one and if the python-qpid-proton library is being installed in the system 2. It requires users - including CI systems, etc - to have cmake installed. 3. It does everything from outside the Python mechanism. The patch proposed in this bug changes the current behavior in favor of using Python's build extensions to compile the library. The patch follows the same steps as you'd do with cmake and it does it *just* for the downloaded tarball. If there's an installed proton-c library, there's nothing to do. If you're building it using cmake from a proton-c dir, it'll keep using cmake normally. The built library doesn't have the same name as the global one and it's installed along with the python binding instead of installing header files and the library itself system wide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-895) Rely on python to build the downloaded tarball
[ https://issues.apache.org/jira/browse/PROTON-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Percoco updated PROTON-895: -- Attachment: 0001-Rely-on-python-to-build-downloaded-tarball.patch Rely on python to build the downloaded tarball -- Key: PROTON-895 URL: https://issues.apache.org/jira/browse/PROTON-895 Project: Qpid Proton Issue Type: Bug Reporter: Flavio Percoco Assignee: Ken Giusti Attachments: 0001-Rely-on-python-to-build-downloaded-tarball.patch Recently, a patch that made python-qpid-proton's setup.py download proton-c and build it whenever it's not found in the system. The patch relied on cmake to build the library as everyone would do when building proton-c. While that works, it's not the right, most pythonic, reliable way to do it. Some reasons why it's not a good thing: 1. It might overwrite a system qpid install if there's one and if the python-qpid-proton library is being installed in the system 2. It requires users - including CI systems, etc - to have cmake installed. 3. It does everything from outside the Python mechanism. The patch proposed in this bug changes the current behavior in favor of using Python's build extensions to compile the library. The patch follows the same steps as you'd do with cmake and it does it *just* for the downloaded tarball. If there's an installed proton-c library, there's nothing to do. If you're building it using cmake from a proton-c dir, it'll keep using cmake normally. The built library doesn't have the same name as the global one and it's installed along with the python binding instead of installing header files and the library itself system wide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-896) change all statis function names to begin with pni_
michael goulish created PROTON-896: -- Summary: change all statis function names to begin with pni_ Key: PROTON-896 URL: https://issues.apache.org/jira/browse/PROTON-896 Project: Qpid Proton Issue Type: Improvement Reporter: michael goulish Priority: Minor Change all the static function names to start with pni_ , and declare all functions as static that ought to be. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-896) change all static function names to begin with pni_
[ https://issues.apache.org/jira/browse/PROTON-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael goulish updated PROTON-896: --- Summary: change all static function names to begin with pni_ (was: change all statis function names to begin with pni_) change all static function names to begin with pni_ --- Key: PROTON-896 URL: https://issues.apache.org/jira/browse/PROTON-896 Project: Qpid Proton Issue Type: Improvement Reporter: michael goulish Priority: Minor Change all the static function names to start with pni_ , and declare all functions as static that ought to be. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-827) Client binding for the go programming language.
[ https://issues.apache.org/jira/browse/PROTON-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14564990#comment-14564990 ] ASF subversion and git services commented on PROTON-827: Commit a301dea4ef9649beec631486a0a50d4990a11c28 in qpid-proton's branch refs/heads/go1 from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=a301dea ] PROTON-827: Simplified examples and Connection error handling. - Simplified non-relevant code in examples (logging, argument handling) - Improved error handling on API see Connection.Error(). Need more on other endpoints. - Added -debug flag to example_test to help debug example problems. Client binding for the go programming language. - Key: PROTON-827 URL: https://issues.apache.org/jira/browse/PROTON-827 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.9 Reporter: Alan Conway Assignee: Alan Conway Develop a reactive API binding in go http://golang.org/, similar to the existing reactive python API illustrated in examples/python. It should follow the pattern of the existing python and C reactive APIs as far as possible while respecting common conventions and idioms of the go langauge. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-518) Add SASL hostname getter/setter
[ https://issues.apache.org/jira/browse/PROTON-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14565005#comment-14565005 ] ASF subversion and git services commented on PROTON-518: Commit 485b23d5009302a35988f9d5fc55ca0217db0bf0 in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=485b23d ] PROTON-518: add setter and getter for using the sasl hostname field Add SASL hostname getter/setter --- Key: PROTON-518 URL: https://issues.apache.org/jira/browse/PROTON-518 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Hiram Chirino Assignee: Robbie Gemmell Fix For: 0.10 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-895) Rely on python to build the downloaded tarball
[ https://issues.apache.org/jira/browse/PROTON-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Percoco updated PROTON-895: -- Attachment: (was: 0001-Rely-on-python-to-build-downloaded-tarball.patch) Rely on python to build the downloaded tarball -- Key: PROTON-895 URL: https://issues.apache.org/jira/browse/PROTON-895 Project: Qpid Proton Issue Type: Bug Reporter: Flavio Percoco Assignee: Ken Giusti Attachments: 0001-Rely-on-python-to-build-downloaded-tarball.patch Recently, a patch that made python-qpid-proton's setup.py download proton-c and build it whenever it's not found in the system. The patch relied on cmake to build the library as everyone would do when building proton-c. While that works, it's not the right, most pythonic, reliable way to do it. Some reasons why it's not a good thing: 1. It might overwrite a system qpid install if there's one and if the python-qpid-proton library is being installed in the system 2. It requires users - including CI systems, etc - to have cmake installed. 3. It does everything from outside the Python mechanism. The patch proposed in this bug changes the current behavior in favor of using Python's build extensions to compile the library. The patch follows the same steps as you'd do with cmake and it does it *just* for the downloaded tarball. If there's an installed proton-c library, there's nothing to do. If you're building it using cmake from a proton-c dir, it'll keep using cmake normally. The built library doesn't have the same name as the global one and it's installed along with the python binding instead of installing header files and the library itself system wide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-895) Rely on python to build the downloaded tarball
[ https://issues.apache.org/jira/browse/PROTON-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Percoco updated PROTON-895: -- Attachment: 0001-Rely-on-python-to-build-downloaded-tarball.patch removed most of the compile/link flags Rely on python to build the downloaded tarball -- Key: PROTON-895 URL: https://issues.apache.org/jira/browse/PROTON-895 Project: Qpid Proton Issue Type: Bug Reporter: Flavio Percoco Assignee: Ken Giusti Attachments: 0001-Rely-on-python-to-build-downloaded-tarball.patch, 0001-Rely-on-python-to-build-downloaded-tarball.patch Recently, a patch that made python-qpid-proton's setup.py download proton-c and build it whenever it's not found in the system. The patch relied on cmake to build the library as everyone would do when building proton-c. While that works, it's not the right, most pythonic, reliable way to do it. Some reasons why it's not a good thing: 1. It might overwrite a system qpid install if there's one and if the python-qpid-proton library is being installed in the system 2. It requires users - including CI systems, etc - to have cmake installed. 3. It does everything from outside the Python mechanism. The patch proposed in this bug changes the current behavior in favor of using Python's build extensions to compile the library. The patch follows the same steps as you'd do with cmake and it does it *just* for the downloaded tarball. If there's an installed proton-c library, there's nothing to do. If you're building it using cmake from a proton-c dir, it'll keep using cmake normally. The built library doesn't have the same name as the global one and it's installed along with the python binding instead of installing header files and the library itself system wide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-334) SASL Implementation for Proton C
[ https://issues.apache.org/jira/browse/PROTON-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14565577#comment-14565577 ] ASF subversion and git services commented on PROTON-334: Commit 1d9eb12a86db6b7490e530b8eaf4bd87f882d79d in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=1d9eb12 ] PROTON-334: Delete removed SASL APIs from PHP binding SASL Implementation for Proton C Key: PROTON-334 URL: https://issues.apache.org/jira/browse/PROTON-334 Project: Qpid Proton Issue Type: Wish Components: proton-c Reporter: Ted Ross Assignee: Andrew Stitcher It would be desirable to have the ability to use a plug-in module for SASL in Proton. The following implementations could then be developed: 1) A portable stand-alone plugin that does ANONYMOUS, PLAIN, and EXTERNAL 2) A Cyrus-Sasl based plugin for Linux 3) A Windows plugin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-827) Client binding for the go programming language.
[ https://issues.apache.org/jira/browse/PROTON-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14565261#comment-14565261 ] ASF subversion and git services commented on PROTON-827: Commit f5c9284c9334034b34b93beead7d9d7b2bc22559 in qpid-proton's branch refs/heads/go1 from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f5c9284 ] PROTON-827: Update README to mention online documentation. Client binding for the go programming language. - Key: PROTON-827 URL: https://issues.apache.org/jira/browse/PROTON-827 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.9 Reporter: Alan Conway Assignee: Alan Conway Develop a reactive API binding in go http://golang.org/, similar to the existing reactive python API illustrated in examples/python. It should follow the pattern of the existing python and C reactive APIs as far as possible while respecting common conventions and idioms of the go langauge. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-827) Client binding for the go programming language.
[ https://issues.apache.org/jira/browse/PROTON-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14565262#comment-14565262 ] ASF subversion and git services commented on PROTON-827: Commit 238617325001b2b0e72ea384d7931a65f86ae63b in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=2386173 ] PROTON-827: Update go README to point to correct location. Client binding for the go programming language. - Key: PROTON-827 URL: https://issues.apache.org/jira/browse/PROTON-827 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.9 Reporter: Alan Conway Assignee: Alan Conway Develop a reactive API binding in go http://golang.org/, similar to the existing reactive python API illustrated in examples/python. It should follow the pattern of the existing python and C reactive APIs as far as possible while respecting common conventions and idioms of the go langauge. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-897) Enhance the Ruby examples
Darryl L. Pierce created PROTON-897: --- Summary: Enhance the Ruby examples Key: PROTON-897 URL: https://issues.apache.org/jira/browse/PROTON-897 Project: Qpid Proton Issue Type: Improvement Components: ruby-binding Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Add a broker example application and standardize the names to reflect which API set they represent; i.e., message_recv.rb, messenger_send.rb and messenger_broker.rb. Add a readme file that explains how to use each of the examples, showing output and giving a brief explanation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-895) Rely on python to build the downloaded tarball
[ https://issues.apache.org/jira/browse/PROTON-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14564887#comment-14564887 ] Ken Giusti commented on PROTON-895: --- Link to reviewboard post: https://reviews.apache.org/r/34809/ Rely on python to build the downloaded tarball -- Key: PROTON-895 URL: https://issues.apache.org/jira/browse/PROTON-895 Project: Qpid Proton Issue Type: Bug Reporter: Flavio Percoco Assignee: Ken Giusti Attachments: 0001-Rely-on-python-to-build-downloaded-tarball.patch Recently, a patch that made python-qpid-proton's setup.py download proton-c and build it whenever it's not found in the system. The patch relied on cmake to build the library as everyone would do when building proton-c. While that works, it's not the right, most pythonic, reliable way to do it. Some reasons why it's not a good thing: 1. It might overwrite a system qpid install if there's one and if the python-qpid-proton library is being installed in the system 2. It requires users - including CI systems, etc - to have cmake installed. 3. It does everything from outside the Python mechanism. The patch proposed in this bug changes the current behavior in favor of using Python's build extensions to compile the library. The patch follows the same steps as you'd do with cmake and it does it *just* for the downloaded tarball. If there's an installed proton-c library, there's nothing to do. If you're building it using cmake from a proton-c dir, it'll keep using cmake normally. The built library doesn't have the same name as the global one and it's installed along with the python binding instead of installing header files and the library itself system wide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
