[jira] [Commented] (PROTON-678) proton-c: (Win 32-bit) pn_post_frame misinterprets variable argument data when ERROR is used
[ https://issues.apache.org/jira/browse/PROTON-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146004#comment-14146004 ] Bozo Dragojevic commented on PROTON-678: Dominic, did you see this error, with you openssl build on windows fix, aka PROTON-660. See my last comment there, I locally also saw a redefinition of ERROR, and transport.c includes platform.h at an awkward place after the protocol.h. proton-c: (Win 32-bit) pn_post_frame misinterprets variable argument data when ERROR is used Key: PROTON-678 URL: https://issues.apache.org/jira/browse/PROTON-678 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: Windows x86-32 Reporter: Dominic Evans Assignee: Andrew Stitcher Attachments: 27_32bit_windows_fix_transport.c.patch For Windows 32bit ERROR is not a uint64_t type, which causes pn_post_frame to misinterpret the passed variable argument data when ERROR is used patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-576) proton-j: codec support for UTF-8 encoding and decoding appears broken?
[
https://issues.apache.org/jira/browse/PROTON-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146193#comment-14146193
]
ASF subversion and git services commented on PROTON-576:
Commit 1627274 from [~gemmellr] in branch 'proton/trunk'
[ https://svn.apache.org/r1627274 ]
PROTON-576: update test to make it compile on Java 6
proton-j: codec support for UTF-8 encoding and decoding appears broken?
---
Key: PROTON-576
URL: https://issues.apache.org/jira/browse/PROTON-576
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Affects Versions: 0.7
Reporter: Dominic Evans
Fix For: 0.8
Attachments: 02_fix_stringtype_encode_decode.patch, PROTON-576.patch
It seems like Proton-J has its own custom UTF-8 encoder, but relies on Java
String's built-in UTF-8 decoder. However, the code doesn't seem quite right
and complex double byte UTF-8 like emoji ('') can quite easily fail to
parse:
| | Cause:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | Message:1 :- Cannot parse String
| | StackTrace:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:48)
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:36)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readRaw(DecoderImpl.java:945)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:172)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:124)
| | at
org.apache.qpid.proton.codec.DynamicTypeConstructor.readValue(DynamicTypeConstructor.java:39)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readObject(DecoderImpl.java:885)
| | at
org.apache.qpid.proton.message.impl.MessageImpl.decode(MessageImpl.java:629)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-576) proton-j: codec support for UTF-8 encoding and decoding appears broken?
[
https://issues.apache.org/jira/browse/PROTON-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146194#comment-14146194
]
Robbie Gemmell commented on PROTON-576:
---
As above, I have altered the test slightly (unfortunately having to disable a
few of the unicode blocks of interest) to allow it to run on Java 6, since that
is what the CI jobs are using and what the poms currently still allow.
I shall now raise a discussion about that on the mailing list.
proton-j: codec support for UTF-8 encoding and decoding appears broken?
---
Key: PROTON-576
URL: https://issues.apache.org/jira/browse/PROTON-576
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Affects Versions: 0.7
Reporter: Dominic Evans
Fix For: 0.8
Attachments: 02_fix_stringtype_encode_decode.patch, PROTON-576.patch
It seems like Proton-J has its own custom UTF-8 encoder, but relies on Java
String's built-in UTF-8 decoder. However, the code doesn't seem quite right
and complex double byte UTF-8 like emoji ('') can quite easily fail to
parse:
| | Cause:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | Message:1 :- Cannot parse String
| | StackTrace:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:48)
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:36)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readRaw(DecoderImpl.java:945)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:172)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:124)
| | at
org.apache.qpid.proton.codec.DynamicTypeConstructor.readValue(DynamicTypeConstructor.java:39)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readObject(DecoderImpl.java:885)
| | at
org.apache.qpid.proton.message.impl.MessageImpl.decode(MessageImpl.java:629)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Timeline to drop Java 6 support for Proton?
Hi all, With Qpid 0.30 we have made the move to requiring Java 7+. Currently, proton still allows for use of Java 6, so I wonder what peoples thoughts are on the timing of a similar move for Proton? I'd personally like to do it soon since Java 6 is EOL, but if not then I think we should at least decide when we will. Robbie Background: I committed a patch yesterday which contained some Java 7 API usage in its tests, and subsequently broke the ASF Jenkins jobs that are still using Java 6 (I'm using 8). Having now noticed this I updated the test to make it compile and run on Java 6, unfortunately having to disable use of some of the input aimed at testing the defect in question. Everything now compiles and the test in question passes, but the overall test run is still failing because it turns out some other new changes in recent days mean there are now a couple of URL tests which fail on Java 6 (but work on Java 8).
Re: svn commit: r1626329 - in /qpid/proton/trunk: proton-c/ proton-c/bindings/perl/ proton-c/bindings/php/ proton-c/bindings/python/ proton-c/bindings/ruby/ proton-c/include/proton/ proton-c/src/ test
The tests are now running again, but a couple of the URL tests still seem
to be failing on the CI job:
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/lastBuild/org.apache.qpid$proton-tests/testReport/
As mentioned in my other post about a timeline for dropping Java6 support,
they seem to work on Java8 (havent tried Java7).
Robbie
On 22 September 2014 21:14, Alan Conway acon...@redhat.com wrote:
My bad, didn't run the java tests. Will fix ASAP and then give myself a
flogging.
On Mon, 2014-09-22 at 19:50 +0100, Robbie Gemmell wrote:
This seems to have broken the Java test runs:
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/664/
On 19 September 2014 22:00, acon...@apache.org wrote:
Author: aconway
Date: Fri Sep 19 21:00:50 2014
New Revision: 1626329
URL: http://svn.apache.org/r1626329
Log:
PROTON-693: Python Url class to wrap C function pni_parse_url
It was pointed out that pni_parse_url is an internal function and the
interface
is not suitable for public API.
Rewrote the URL parser as a proper swigable C API pn_url_*. This gets
rid
of the
need for previous swig insanity and is cleaner all round.
Internally still uses the pni_parse_url parser, we can clean that up
later.
Added:
qpid/proton/trunk/proton-c/include/proton/url.h
qpid/proton/trunk/proton-c/src/url.c
Modified:
qpid/proton/trunk/proton-c/CMakeLists.txt
qpid/proton/trunk/proton-c/bindings/perl/perl.i
qpid/proton/trunk/proton-c/bindings/php/php.i
qpid/proton/trunk/proton-c/bindings/python/cproton.i
qpid/proton/trunk/proton-c/bindings/python/proton.py
qpid/proton/trunk/proton-c/bindings/ruby/ruby.i
qpid/proton/trunk/proton-c/include/proton/cproton.i
qpid/proton/trunk/tests/python/proton_tests/url.py
Modified: qpid/proton/trunk/proton-c/CMakeLists.txt
URL:
http://svn.apache.org/viewvc/qpid/proton/trunk/proton-c/CMakeLists.txt?rev=1626329r1=1626328r2=1626329view=diff
==
--- qpid/proton/trunk/proton-c/CMakeLists.txt (original)
+++ qpid/proton/trunk/proton-c/CMakeLists.txt Fri Sep 19 21:00:50 2014
@@ -270,6 +270,7 @@ set (qpid-proton-core
src/object/iterator.c
src/util.c
+ src/url.c
src/error.c
src/buffer.c
src/parser.c
Modified: qpid/proton/trunk/proton-c/bindings/perl/perl.i
URL:
http://svn.apache.org/viewvc/qpid/proton/trunk/proton-c/bindings/perl/perl.i?rev=1626329r1=1626328r2=1626329view=diff
==
--- qpid/proton/trunk/proton-c/bindings/perl/perl.i (original)
+++ qpid/proton/trunk/proton-c/bindings/perl/perl.i Fri Sep 19 21:00:50
2014
@@ -8,6 +8,7 @@
#include proton/messenger.h
#include proton/ssl.h
#include proton/driver_extras.h
+#include proton/url.h
%}
%include cstring.i
Modified: qpid/proton/trunk/proton-c/bindings/php/php.i
URL:
http://svn.apache.org/viewvc/qpid/proton/trunk/proton-c/bindings/php/php.i?rev=1626329r1=1626328r2=1626329view=diff
==
--- qpid/proton/trunk/proton-c/bindings/php/php.i (original)
+++ qpid/proton/trunk/proton-c/bindings/php/php.i Fri Sep 19 21:00:50
2014
@@ -29,6 +29,7 @@
%header %{
/* Include the headers needed by the code in this wrapper file */
#include proton/types.h
+#include proton/url.h
#include proton/message.h
#include proton/driver.h
#include proton/driver_extras.h
Modified: qpid/proton/trunk/proton-c/bindings/python/cproton.i
URL:
http://svn.apache.org/viewvc/qpid/proton/trunk/proton-c/bindings/python/cproton.i?rev=1626329r1=1626328r2=1626329view=diff
==
--- qpid/proton/trunk/proton-c/bindings/python/cproton.i (original)
+++ qpid/proton/trunk/proton-c/bindings/python/cproton.i Fri Sep 19
21:00:50 2014
@@ -23,6 +23,7 @@
#include winsock2.h
#endif
#include proton/engine.h
+#include proton/url.h
#include proton/message.h
#include proton/sasl.h
#include proton/driver.h
@@ -280,41 +281,4 @@ int pn_ssl_get_peer_hostname(pn_ssl_t *s
}
%}
-
-/**
- pni_parse_url(char* url, char **scheme, char **user, char **pass,
char
**host, char **port, char **path)
- The following type maps convert this into a python function that
taks
a URL string argument
- and returns a list of strings [scheme, user, pass, host, port,
path]
- This probably could be done more neatly.
-*/
-
-// Typemap to copy the url string as it will be modified by parse_url
-%typemap(in,noblock=1,fragment=SWIG_AsCharPtrAndSize) char *url (int
res, char *t = 0, size_t n = 0, int
[jira] [Commented] (PROTON-576) proton-j: codec support for UTF-8 encoding and decoding appears broken?
[
https://issues.apache.org/jira/browse/PROTON-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146273#comment-14146273
]
ASF subversion and git services commented on PROTON-576:
Commit 1627298 from [~gemmellr] in branch 'proton/trunk'
[ https://svn.apache.org/r1627298 ]
PROTON-576: updates to bring things into line with the patch on the JIRA,
rather than a stale older version I actually applied (not having a good day :P)
proton-j: codec support for UTF-8 encoding and decoding appears broken?
---
Key: PROTON-576
URL: https://issues.apache.org/jira/browse/PROTON-576
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Affects Versions: 0.7
Reporter: Dominic Evans
Fix For: 0.8
Attachments: 02_fix_stringtype_encode_decode.patch, PROTON-576.patch
It seems like Proton-J has its own custom UTF-8 encoder, but relies on Java
String's built-in UTF-8 decoder. However, the code doesn't seem quite right
and complex double byte UTF-8 like emoji ('') can quite easily fail to
parse:
| | Cause:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | Message:1 :- Cannot parse String
| | StackTrace:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:48)
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:36)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readRaw(DecoderImpl.java:945)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:172)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:124)
| | at
org.apache.qpid.proton.codec.DynamicTypeConstructor.readValue(DynamicTypeConstructor.java:39)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readObject(DecoderImpl.java:885)
| | at
org.apache.qpid.proton.message.impl.MessageImpl.decode(MessageImpl.java:629)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Timeline to drop Java 6 support for Proton?
This is just testing... can't you have a java7 tests folder? you would be able to still have java7 specific tests. On Sep 24, 2014, at 7:13 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote: Hi all, With Qpid 0.30 we have made the move to requiring Java 7+. Currently, proton still allows for use of Java 6, so I wonder what peoples thoughts are on the timing of a similar move for Proton? I'd personally like to do it soon since Java 6 is EOL, but if not then I think we should at least decide when we will. Robbie Background: I committed a patch yesterday which contained some Java 7 API usage in its tests, and subsequently broke the ASF Jenkins jobs that are still using Java 6 (I'm using 8). Having now noticed this I updated the test to make it compile and run on Java 6, unfortunately having to disable use of some of the input aimed at testing the defect in question. Everything now compiles and the test in question passes, but the overall test run is still failing because it turns out some other new changes in recent days mean there are now a couple of URL tests which fail on Java 6 (but work on Java 8).
Re: Timeline to drop Java 6 support for Proton?
The compilation issue I missed in the patch was test-only this time, but it could have as easily been in non-test code. The other tests now failing might actually point to some functionality under test not working under Java 6 at runtime though, which is more of an issue. If the tests showing it didnt exist, or the CI job had been using either the current or previous major Java release, then that might not have been noticed prior to release. Whether it compiles or not isnt the only reason to drop support. Releasing new versions that people can continue deploying to EOL plaforms in years to come isnt necessarily helping anyone if we aren't in fact properly ensuring it really works there. If we dont tuly support it, we should probably cut it. Whether we do it now, or later, I just think it would be a good idea to actually decide on a timeline. Robbie On 24 September 2014 14:11, Clebert Suconic csuco...@redhat.com wrote: This is just testing... can't you have a java7 tests folder? you would be able to still have java7 specific tests. On Sep 24, 2014, at 7:13 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote: Hi all, With Qpid 0.30 we have made the move to requiring Java 7+. Currently, proton still allows for use of Java 6, so I wonder what peoples thoughts are on the timing of a similar move for Proton? I'd personally like to do it soon since Java 6 is EOL, but if not then I think we should at least decide when we will. Robbie Background: I committed a patch yesterday which contained some Java 7 API usage in its tests, and subsequently broke the ASF Jenkins jobs that are still using Java 6 (I'm using 8). Having now noticed this I updated the test to make it compile and run on Java 6, unfortunately having to disable use of some of the input aimed at testing the defect in question. Everything now compiles and the test in question passes, but the overall test run is still failing because it turns out some other new changes in recent days mean there are now a couple of URL tests which fail on Java 6 (but work on Java 8).
[jira] [Commented] (PROTON-661) pn_message_save_* do not return correct message size when PN_OVERFLOW
[ https://issues.apache.org/jira/browse/PROTON-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146627#comment-14146627 ] ASF subversion and git services commented on PROTON-661: Commit 1627380 from r...@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1627380 ] PROTON-661: applied patch from miguel pn_message_save_* do not return correct message size when PN_OVERFLOW - Key: PROTON-661 URL: https://issues.apache.org/jira/browse/PROTON-661 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4, 0.5, 0.7 Environment: All plataforms Reporter: Miguel da Rocha Correia Lima Priority: Critical Attachments: landix-ret-size-message-save.patch Expected behavior: When you use pn_message_save* functions API, you pass char *data and size_t *size. If the size IS NOT enough to save mesage body text, this functions return in size_t *size variable, the necessary buffer size and return PN_OVERFLOW status. Behavior observed: The pn_message_save* functions API return PN_OVERFLOW status and DO NOT return a correct value of necessary buffer. Patch to fix expected behavior is attached: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-661) pn_message_save_* do not return correct message size when PN_OVERFLOW
[ https://issues.apache.org/jira/browse/PROTON-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming reassigned PROTON-661: -- Assignee: Rafael H. Schloming pn_message_save_* do not return correct message size when PN_OVERFLOW - Key: PROTON-661 URL: https://issues.apache.org/jira/browse/PROTON-661 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4, 0.5, 0.7 Environment: All plataforms Reporter: Miguel da Rocha Correia Lima Assignee: Rafael H. Schloming Priority: Critical Fix For: 0.8 Attachments: landix-ret-size-message-save.patch Expected behavior: When you use pn_message_save* functions API, you pass char *data and size_t *size. If the size IS NOT enough to save mesage body text, this functions return in size_t *size variable, the necessary buffer size and return PN_OVERFLOW status. Behavior observed: The pn_message_save* functions API return PN_OVERFLOW status and DO NOT return a correct value of necessary buffer. Patch to fix expected behavior is attached: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-565) Modify the Messenger to use the Collector API.
[ https://issues.apache.org/jira/browse/PROTON-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-565: --- Fix Version/s: (was: 0.8) Modify the Messenger to use the Collector API. -- Key: PROTON-565 URL: https://issues.apache.org/jira/browse/PROTON-565 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Rajith Attapattu Assignee: Rajith Attapattu Attachments: PROTON-565.part1.patch Modify the Messenger to use the Collector API instead of querying the for state changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-594) In tree builds with cmake causes issues when running python based tests
[ https://issues.apache.org/jira/browse/PROTON-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-594: --- Fix Version/s: (was: 0.8) In tree builds with cmake causes issues when running python based tests --- Key: PROTON-594 URL: https://issues.apache.org/jira/browse/PROTON-594 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Rajith Attapattu Assignee: Rafael H. Schloming If we do an in-tree build it causes path issues when trying to run the python based tests against the java code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-343) Add a pluggable Proton logging layer
[ https://issues.apache.org/jira/browse/PROTON-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-343: --- Fix Version/s: (was: 0.8) Add a pluggable Proton logging layer Key: PROTON-343 URL: https://issues.apache.org/jira/browse/PROTON-343 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Philip Harvey Assignee: Philip Harvey Attachments: 0001-PROTON-343-sketched-out-the-Java-parts-of-the-propos.patch Applications that use Proton sometimes want Proton to produce logging. Goals * Proton should provide a default logging implementation. * It should be easy for Proton client code to provide custom logging implementation, e.g. one that uses the same third party logging framework as their application code. * Proton should not have a compile-time dependency on a third party logging framework * Proton's log output is considered to be part of its public interface. Therefore, in the spirit of Proton's cross-language consistency goals, this output should be consistent between proton-c and proton-j. * The goals that general-purpose logging frameworks try to meet - performance, ease of use etc - also apply. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-643) Malloc result used without testing for null
[
https://issues.apache.org/jira/browse/PROTON-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming updated PROTON-643:
---
Fix Version/s: (was: 0.8)
Malloc result used without testing for null
---
Key: PROTON-643
URL: https://issues.apache.org/jira/browse/PROTON-643
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Reporter: Chuck Rolke
{noformat}
pn_buffer_t *buf = (pn_buffer_t *) malloc(sizeof(pn_buffer_t));
buf-capacity = capacity;
{noformat}
Many calls to malloc are properly checked but not all.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-589) Implement passive mode for proton-j messenger
[ https://issues.apache.org/jira/browse/PROTON-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-589: --- Fix Version/s: (was: 0.8) Implement passive mode for proton-j messenger - Key: PROTON-589 URL: https://issues.apache.org/jira/browse/PROTON-589 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Rajith Attapattu Assignee: Rajith Attapattu Passive mode allows the file descriptors for messenger to be serviced by an external loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-515: --- Fix Version/s: (was: 0.8) Port to OpenVMS --- Key: PROTON-515 URL: https://issues.apache.org/jira/browse/PROTON-515 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.6 Environment: OpenVMS Reporter: Tomas Soltys Labels: OpenVMS, patch Attachments: codec.c.patch, driver.c.patch, message.c.patch There is a need for proton-c port to OpenVMS platform. To make proton-c functional on OpenVMS few changes in the source code are required. Here is list of files I have identified which require some attention: proton-c/src/platform_fmt.h proton-c/src/posix/driver.c proton-c/src/object/object.c proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-632) [python] Add user context handle for all objects provided by the binding
[ https://issues.apache.org/jira/browse/PROTON-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-632: --- Fix Version/s: (was: 0.8) [python] Add user context handle for all objects provided by the binding Key: PROTON-632 URL: https://issues.apache.org/jira/browse/PROTON-632 Project: Qpid Proton Issue Type: Improvement Components: python-binding Affects Versions: 0.7 Reporter: Ken Giusti Assignee: Ken Giusti Purely syntactic sugar, but we should add a 'context' field to the API of all of the singleton objects (connection, link, session, delivery, etc) provided by the binding. This context field would be available for the user application - exactly like the get/set context methods in the C engine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-697) SChannel SSL/TLS support for Proton-c on Windows
Cliff Jansen created PROTON-697: --- Summary: SChannel SSL/TLS support for Proton-c on Windows Key: PROTON-697 URL: https://issues.apache.org/jira/browse/PROTON-697 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.8 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen This JIRA tracks the progress of completing SChannel functionality in Proton beyond the start in PROTON-581. The target is Proton 0.9. This includes support for incoming connections client side certificates Windows registry and file based certificate stores Control over certificate name checking -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-581) SSL/TLS support for Proton-c on Windows
[ https://issues.apache.org/jira/browse/PROTON-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14147236#comment-14147236 ] Cliff Jansen commented on PROTON-581: - See https://reviews.apache.org/r/26013 for the current best patch. This implementation will not complete in time for Proton 0.8, so it is being reduced in scope to just handle client connections without client side-certificates. See PROTON-697 for progress on the full version targeted for Proton 0.9. SSL/TLS support for Proton-c on Windows --- Key: PROTON-581 URL: https://issues.apache.org/jira/browse/PROTON-581 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.6, 0.7 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Attachments: schannel_0.patch Provide a Microsoft SChannel based SSL/TLS layer for Proton-c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-689) Python binding does not expose transport error details
[ https://issues.apache.org/jira/browse/PROTON-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14147257#comment-14147257 ] ASF subversion and git services commented on PROTON-689: Commit 1627444 from r...@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1627444 ] PROTON-689: added a condition to the transport along with bindings to expose it Python binding does not expose transport error details -- Key: PROTON-689 URL: https://issues.apache.org/jira/browse/PROTON-689 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.8 Reporter: Ken Giusti Fix For: 0.8 The proton event model defines a TRANSPORT_ERROR event, but when the event occurs there is no way to extract the error code nor the error text from the transport when using the python binding. The connection class exports the error code via the 'error' property. I'd like to see an 'error' property added to the Transport class, and an 'error_text' property to both the Transport and the Connection for completeness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-689) Python binding does not expose transport error details
[ https://issues.apache.org/jira/browse/PROTON-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14147264#comment-14147264 ] Rafael H. Schloming commented on PROTON-689: I added a Transport.condition property to access error details. The pn_condition_t object is very similar to pn_error_t except rather than a numeric code it has a symbolic name and it can also carry a map with additional parameters. In python it seems kind of confusing and pointless to have both concepts (we should possibly merge them in C also), so I opted to expose the error details as a condition rather than an error since pn_condition_t can carry the full range of protocol errors and info, whereas pn_error_t cannot. I don't really know why Connection has an error property. Pretty much anything that generates an error should be exposed to the binding via exceptions. I commented out the error property and none of the tests failed, so I'm thinking we should deprecate the error property on connection and use the Connection's condition property instead. Let me know if what I have added works for you. Python binding does not expose transport error details -- Key: PROTON-689 URL: https://issues.apache.org/jira/browse/PROTON-689 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.8 Reporter: Ken Giusti Fix For: 0.8 The proton event model defines a TRANSPORT_ERROR event, but when the event occurs there is no way to extract the error code nor the error text from the transport when using the python binding. The connection class exports the error code via the 'error' property. I'd like to see an 'error' property added to the Transport class, and an 'error_text' property to both the Transport and the Connection for completeness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-689) Python binding does not expose transport error details
[ https://issues.apache.org/jira/browse/PROTON-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-689. Resolution: Fixed Python binding does not expose transport error details -- Key: PROTON-689 URL: https://issues.apache.org/jira/browse/PROTON-689 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.8 Reporter: Ken Giusti Assignee: Rafael H. Schloming Fix For: 0.8 The proton event model defines a TRANSPORT_ERROR event, but when the event occurs there is no way to extract the error code nor the error text from the transport when using the python binding. The connection class exports the error code via the 'error' property. I'd like to see an 'error' property added to the Transport class, and an 'error_text' property to both the Transport and the Connection for completeness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
