[jira] [Commented] (QPIDJMS-191) Add a WebSocket based transport to the client
[ https://issues.apache.org/jira/browse/QPIDJMS-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15380269#comment-15380269 ] ASF subversion and git services commented on QPIDJMS-191: - Commit d5cc7c32e54081d56697e7c50718803df4c51ee2 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=d5cc7c3 ] QPIDJMS-191 Pull in latest netty release > Add a WebSocket based transport to the client > - > > Key: QPIDJMS-191 > URL: https://issues.apache.org/jira/browse/QPIDJMS-191 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Affects Versions: 0.10.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.11.0 > > > Add a WebSocket based Transport to the client -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-191) Add a WebSocket based transport to the client
[ https://issues.apache.org/jira/browse/QPIDJMS-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15380263#comment-15380263 ] ASF subversion and git services commented on QPIDJMS-191: - Commit d7a1e25e9362a9f9a34666730ed295c550ba87b3 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=d7a1e25 ] QPIDJMS-191 Some additional cleanups simplify the handler chain by creating a single common handler and specializing for socket vs web socket. Add explicit pong handling to the WS case. > Add a WebSocket based transport to the client > - > > Key: QPIDJMS-191 > URL: https://issues.apache.org/jira/browse/QPIDJMS-191 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Affects Versions: 0.10.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.11.0 > > > Add a WebSocket based Transport to the client -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1237) C connection_engine interface and libuv example driver.
[ https://issues.apache.org/jira/browse/PROTON-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15380156#comment-15380156 ] ASF subversion and git services commented on PROTON-1237: - Commit e9f9eef00e50f93c49f2eeec66bcfa9045e771d6 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=e9f9eef ] PROTON-1237: c: connection_engine event logging. Environment variable PN_TRACE_EVENT=1 prints proton C event names using the transport trace log facility. Mostly useful for low-level debugging while doing binding work but might be of use to users in some cases. > C connection_engine interface and libuv example driver. > --- > > Key: PROTON-1237 > URL: https://issues.apache.org/jira/browse/PROTON-1237 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.12.2 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.14.0 > > > The C++ and Ruby bindings have a connection_engine interface: it gathers > together the functionality of pn_connection pn_transport and pn_collector to > enable handler-style programming against a single connection, with no > assumptions about IO or threading. > Some of this can be back-ported to C to make it easier to do reactive > programming in C without using the pn_reactor (which forces IO and threading > choices on the user) > Create a C version of the C++ io::connection_engine and use it as the > implementation of the C++ and Go binding engines. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1258) No transport_close event is generated on the listening side of the connection
[ https://issues.apache.org/jira/browse/PROTON-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15380091#comment-15380091 ] ASF subversion and git services commented on PROTON-1258: - Commit 35f425bc40b3e4ede43d65cd4d7e9ecd98b0a58a in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=35f425b ] PROTON-1258: Make transport events more consistent on client and server - This is almost the same as 4a601011 but with some review fixes from acon...@redhat.com > No transport_close event is generated on the listening side of the connection > - > > Key: PROTON-1258 > URL: https://issues.apache.org/jira/browse/PROTON-1258 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.14.0 > > > Transport event handling is inconsistent between the listening and connecting > sides of an AMQP connection: > On the client the transport events happen as they should - you always get > transport_open an optional transport_error and transport_close. > On the server you get the transport_open, but no transport_close. However if > the connection is interrupted for some reason (say the socket disconnects) > then you will transport_error, followed by transport_close. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1166) installer forgets to install io subfolder of includes
[ https://issues.apache.org/jira/browse/PROTON-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1166. - Resolution: Cannot Reproduce Assignee: Andrew Stitcher (was: Cliff Jansen) > installer forgets to install io subfolder of includes > - > > Key: PROTON-1166 > URL: https://issues.apache.org/jira/browse/PROTON-1166 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0 >Reporter: Roman Puls >Assignee: Andrew Stitcher >Priority: Trivial > Fix For: 0.14.0 > > > I just installed qpid HEAD-45390a9, and currently the install script does not > copy over the io folder from the includes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1166) installer forgets to install io subfolder of includes
[ https://issues.apache.org/jira/browse/PROTON-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379942#comment-15379942 ] Andrew Stitcher commented on PROTON-1166: - I think you may be building incorrectly - what do you mean by "install script"? Building with the install target generated by cmake creates an io directory in the install area. [tested with master 4a6010110296846e3c77defc0558a45d8792d3b5] > installer forgets to install io subfolder of includes > - > > Key: PROTON-1166 > URL: https://issues.apache.org/jira/browse/PROTON-1166 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0 >Reporter: Roman Puls >Assignee: Cliff Jansen >Priority: Trivial > Fix For: 0.14.0 > > > I just installed qpid HEAD-45390a9, and currently the install script does not > copy over the io folder from the includes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1238) proton::connection objects (and others too) don't have useful names
[ https://issues.apache.org/jira/browse/PROTON-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379857#comment-15379857 ] Andrew Stitcher commented on PROTON-1238: - It would make sense to add a name member to proton::endpoint which would allow you to get a name for all endpoints. A reasonable name would just be an object type with an appended low integer. for example "connection-1". This could be implemented with an monotonically increasing atomic either per endpoint type or for all endpoints. > proton::connection objects (and others too) don't have useful names > --- > > Key: PROTON-1238 > URL: https://issues.apache.org/jira/browse/PROTON-1238 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.14.0 > > > [Issue "reimagined" to fit the actual use case.] > If you want to report to the user and refer to a connection (and probably > other proton objects) there is no easy way to get a unique name that we can > use to refer to a connection. > The name is distinct from the url used to create the connection (although url > would work as a name). The name is also distinct from a printable > representation of the object. > Originally the issue was: > Although the user could just remember whatever url they used to create a > given connection, it is duplicative when the library has the info around. > Also if it is not provided then the user has to plumb to info to places it is > needed inside the event handlers, however the handlers will already get the > connection context object anyway so that is unecessary and an extra burden. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1258) No transport_close event is generated on the listening side of the connection
[ https://issues.apache.org/jira/browse/PROTON-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379856#comment-15379856 ] ASF subversion and git services commented on PROTON-1258: - Commit 27f296ccdcbf720e03eee9e99ec88116887fc817 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=27f296c ] Revert "PROTON-1258: Make transport events more consistent on client and server" This reverts commit 4a6010110296846e3c77defc0558a45d8792d3b5. This commit crashes the cpp_mt_example_test in a release build (but not in a debug or reldbg build which is worth investigating separtely) The connection engine relies on the events generated by correct use of pn_transport_t. PROTON-1258 is a reactor bug: the reactor needs to be fixed to close the transport correctly, before unbinding it, so that it can generate the proper close events in the proper sequence. The handler should not be involved. > No transport_close event is generated on the listening side of the connection > - > > Key: PROTON-1258 > URL: https://issues.apache.org/jira/browse/PROTON-1258 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.14.0 > > > Transport event handling is inconsistent between the listening and connecting > sides of an AMQP connection: > On the client the transport events happen as they should - you always get > transport_open an optional transport_error and transport_close. > On the server you get the transport_open, but no transport_close. However if > the connection is interrupted for some reason (say the socket disconnects) > then you will transport_error, followed by transport_close. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1258) No transport_close event is generated on the listening side of the connection
[ https://issues.apache.org/jira/browse/PROTON-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379855#comment-15379855 ] ASF subversion and git services commented on PROTON-1258: - Commit 27f296ccdcbf720e03eee9e99ec88116887fc817 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=27f296c ] Revert "PROTON-1258: Make transport events more consistent on client and server" This reverts commit 4a6010110296846e3c77defc0558a45d8792d3b5. This commit crashes the cpp_mt_example_test in a release build (but not in a debug or reldbg build which is worth investigating separtely) The connection engine relies on the events generated by correct use of pn_transport_t. PROTON-1258 is a reactor bug: the reactor needs to be fixed to close the transport correctly, before unbinding it, so that it can generate the proper close events in the proper sequence. The handler should not be involved. > No transport_close event is generated on the listening side of the connection > - > > Key: PROTON-1258 > URL: https://issues.apache.org/jira/browse/PROTON-1258 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.14.0 > > > Transport event handling is inconsistent between the listening and connecting > sides of an AMQP connection: > On the client the transport events happen as they should - you always get > transport_open an optional transport_error and transport_close. > On the server you get the transport_open, but no transport_close. However if > the connection is interrupted for some reason (say the socket disconnects) > then you will transport_error, followed by transport_close. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1238) proton::connection objects (and others too) don't have useful names
[ https://issues.apache.org/jira/browse/PROTON-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-1238: Description: [Issue "reimagined" to fit the actual use case.] If you want to report to the user and refer to a connection (and probably other proton objects) there is no easy way to get a unique name that we can use to refer to a connection. The name is distinct from the url used to create the connection (although url would work as a name). The name is also distinct from a printable representation of the object. Originally the issue was: Although the user could just remember whatever url they used to create a given connection, it is duplicative when the library has the info around. Also if it is not provided then the user has to plumb to info to places it is needed inside the event handlers, however the handlers will already get the connection context object anyway so that is unecessary and an extra burden. was: [Issue "reimagined" to fit the actual use case.] If you want to report to the user and refer to a connection (and probably other proton objects) there is no easy way to get a name that we can use to refer to a connection. The name is distinct from the url used to create the connection (although url would work as a name). The name is also distinct from a printable representation of the object. Originally the issue was: Although the user could just remember whatever url they used to create a given connection, it is duplicative when the library has the info around. Also if it is not provided then the user has to plumb to info to places it is needed inside the event handlers, however the handlers will already get the connection context object anyway so that is unecessary and an extra burden. > proton::connection objects (and others too) don't have useful names > --- > > Key: PROTON-1238 > URL: https://issues.apache.org/jira/browse/PROTON-1238 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.14.0 > > > [Issue "reimagined" to fit the actual use case.] > If you want to report to the user and refer to a connection (and probably > other proton objects) there is no easy way to get a unique name that we can > use to refer to a connection. > The name is distinct from the url used to create the connection (although url > would work as a name). The name is also distinct from a printable > representation of the object. > Originally the issue was: > Although the user could just remember whatever url they used to create a > given connection, it is duplicative when the library has the info around. > Also if it is not provided then the user has to plumb to info to places it is > needed inside the event handlers, however the handlers will already get the > connection context object anyway so that is unecessary and an extra burden. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1238) proton::connection objects (and others too) don't have useful names
[ https://issues.apache.org/jira/browse/PROTON-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-1238: Description: [Issue "reimagined" to fit the actual use case.] If you want to report to the user and refer to a connection (and probably other proton objects) there is no easy way to get a name that we can use to refer to a connection. The name is distinct from the url used to create the connection (although url would work as a name). The name is also distinct from a printable representation of the object. Originally the issue was: Although the user could just remember whatever url they used to create a given connection, it is duplicative when the library has the info around. Also if it is not provided then the user has to plumb to info to places it is needed inside the event handlers, however the handlers will already get the connection context object anyway so that is unecessary and an extra burden. was: Although the user could just remember whatever url they used to create a given connection, it is duplicative when the library has the info around. Also if it is not provided then the user has to plumb to info to places it is needed inside the event handlers, however the handlers will already get the connection context object anyway so that is unecessary and an extra burden. > proton::connection objects (and others too) don't have useful names > --- > > Key: PROTON-1238 > URL: https://issues.apache.org/jira/browse/PROTON-1238 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.14.0 > > > [Issue "reimagined" to fit the actual use case.] > If you want to report to the user and refer to a connection (and probably > other proton objects) there is no easy way to get a name that we can use to > refer to a connection. > The name is distinct from the url used to create the connection (although url > would work as a name). The name is also distinct from a printable > representation of the object. > Originally the issue was: > Although the user could just remember whatever url they used to create a > given connection, it is duplicative when the library has the info around. > Also if it is not provided then the user has to plumb to info to places it is > needed inside the event handlers, however the handlers will already get the > connection context object anyway so that is unecessary and an extra burden. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1238) proton::connection objects (and others too) don't have useful names
[ https://issues.apache.org/jira/browse/PROTON-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-1238: Summary: proton::connection objects (and others too) don't have useful names (was: There is no way to query proton::connection for the url it was created with.) > proton::connection objects (and others too) don't have useful names > --- > > Key: PROTON-1238 > URL: https://issues.apache.org/jira/browse/PROTON-1238 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.14.0 > > > Although the user could just remember whatever url they used to create a > given connection, it is duplicative when the library has the info around. > Also if it is not provided then the user has to plumb to info to places it is > needed inside the event handlers, however the handlers will already get the > connection context object anyway so that is unecessary and an extra burden. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-191) Add a WebSocket based transport to the client
[ https://issues.apache.org/jira/browse/QPIDJMS-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379711#comment-15379711 ] ASF subversion and git services commented on QPIDJMS-191: - Commit 0155e418ac60fe8d5c084cb143dcbc9e68379012 in qpid-jms's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=0155e41 ] QPIDJMS-191: initialise the SslHandler before the connect attempt begins, ensures certain config issues fail fast without attempting a socket connection > Add a WebSocket based transport to the client > - > > Key: QPIDJMS-191 > URL: https://issues.apache.org/jira/browse/QPIDJMS-191 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Affects Versions: 0.10.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.11.0 > > > Add a WebSocket based Transport to the client -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-191) Add a WebSocket based transport to the client
[ https://issues.apache.org/jira/browse/QPIDJMS-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379712#comment-15379712 ] ASF subversion and git services commented on QPIDJMS-191: - Commit 7596c7b7ffd78c41bdca45821a4c2cac0ee32eee in qpid-jms's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=7596c7b ] QPIDJMS-191: rename handler creation method and update the level of some log messages > Add a WebSocket based transport to the client > - > > Key: QPIDJMS-191 > URL: https://issues.apache.org/jira/browse/QPIDJMS-191 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Affects Versions: 0.10.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.11.0 > > > Add a WebSocket based Transport to the client -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1254) Proton-J opens redundant sockets during reconnect and never frees those resources
[ https://issues.apache.org/jira/browse/PROTON-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zoltan Varga closed PROTON-1254. Resolution: Invalid The issue was in the upper layer, how the Proton-J close() was handled. The upper layer used " if (this.state != State.CLOSED)" check to free the resources. It looks like client code has to call close() for all proton-j layers regardless the state. > Proton-J opens redundant sockets during reconnect and never frees those > resources > - > > Key: PROTON-1254 > URL: https://issues.apache.org/jira/browse/PROTON-1254 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.13.0 > Environment: Java 1.8 (latest) on Windows and Linux >Reporter: Zoltan Varga > > Repro: > - Run TCPView (WIndows) or use TcpDump on Linux > - Start sending AMQP messages to pier > - Disconnect network cable > - Connect network cable again > - Repeat the two steps above several times > - Check the sockets opened and held by the Java process for the used remote > address/port > Notice there are sockets left opened in undefined state (either ESTABLISHED > or CLOSE_WAIT) > The redundant sockets will be never released. Only exiting the application > will release them. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1257) c++ cached_map core dump on assignment
[ https://issues.apache.org/jira/browse/PROTON-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen closed PROTON-1257. Resolution: Fixed > c++ cached_map core dump on assignment > -- > > Key: PROTON-1257 > URL: https://issues.apache.org/jira/browse/PROTON-1257 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.14.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Critical > Fix For: 0.14.0 > > > The copy created is deleted but the pn_unique_ptr still points to the > released memory. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1255) connection_engine support for built-in proton SSL/SASL
[ https://issues.apache.org/jira/browse/PROTON-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379616#comment-15379616 ] Alan Conway commented on PROTON-1255: - Add the following examples and fix any issues (hopefully none) that arise: 1. connection_engine example showing how to use protons built-in SSL, adapted from existing SSL example. 2. Go example using native Go SSL with the proton engine. Both examples should print the authenticated SSL user from a proton on-open handler. > connection_engine support for built-in proton SSL/SASL > -- > > Key: PROTON-1255 > URL: https://issues.apache.org/jira/browse/PROTON-1255 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, go-binding, proton-c >Affects Versions: 0.12.2 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Critical > > Make sure proton's built-in SSL and SASL work fully with the connection > engine for all bindings that have one (C, C++, Go) > The connection_engine also allows a secure connection to be established > externally. Check that we have sufficient hooks to pass external security > principal info to the handler via connection and transport properties. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7318) [Java Broker] Refactor existing ACL plugin code
[ https://issues.apache.org/jira/browse/QPID-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379612#comment-15379612 ] ASF subversion and git services commented on QPID-7318: --- Commit 1752846 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1752846 ] QPID-7318 : Reduce code duplication in ACL implementations > [Java Broker] Refactor existing ACL plugin code > --- > > Key: QPID-7318 > URL: https://issues.apache.org/jira/browse/QPID-7318 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > > While the aim is to redesign the ACL implementation in the v6.2 or v7.0 > timeframe, there is still utility in tidying up the existing ACL > implementation a bit. In particular by separating out functions and > providing a better encapsulation, we will make the job of writing automated > upgraders to any new ACL implementation substantially easier. > As a first step we can separate out the parsing of the ACL file, from the > "rule based" implementation of ACLs. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-523) Configurable SSLEngine
[ https://issues.apache.org/jira/browse/PROTON-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-523: --- Priority: Major (was: Critical) > Configurable SSLEngine > -- > > Key: PROTON-523 > URL: https://issues.apache.org/jira/browse/PROTON-523 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-j >Reporter: Piotr Kliczewski > > We need to configure SSLEngine using our own trust and key stores and > password for both. > We propose following configuration options: > - provide locations of stores and passwords > - provide SSLContext > - provide SSLEngine -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-356) PHP bindings are not built on MacOS 10.8
[ https://issues.apache.org/jira/browse/PROTON-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-356. -- Resolution: Won't Fix > PHP bindings are not built on MacOS 10.8 > > > Key: PROTON-356 > URL: https://issues.apache.org/jira/browse/PROTON-356 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: MacOS X 10.8, Homebrew >Reporter: Serge Smertin >Priority: Critical > Labels: osx > > it's not possible to build PHP extension for MacOS, as it gives linking > error. Relates to issue - https://issues.apache.org/jira/browse/PROTON-108, > which is not resolved properly. > Short-term viable solution: > - Attach *.so files to this ticket for macos x exactly > Long-term solution: > - Make proper linking -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1168) 2-way Authentication via Certificates Fails in Proton-J
[
https://issues.apache.org/jira/browse/PROTON-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross closed PROTON-1168.
---
Resolution: Cannot Reproduce
Jack, let us know if you get new information on this.
> 2-way Authentication via Certificates Fails in Proton-J
> ---
>
> Key: PROTON-1168
> URL: https://issues.apache.org/jira/browse/PROTON-1168
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Affects Versions: 0.12.0
> Environment: Ubuntu 15.10 & RHEL 7
> Qpid Dispatch 0.5 & 0.6
> Proton-C 0.12 and Proton-J 0.12
>Reporter: Jack Gibson
>Priority: Critical
> Attachments: PROTON-1168_reactor_ssl.patch,
> my_qdrouterd_B_standalone.conf, recv_with_ssl.c, send_with_ssl.c,
> ssl_logs1.tar.gz
>
>
> Using qpid dispatch, we are unable to enable 2 way SSL with proton-j but able
> to with proton-c.
> To reproduce use the attached config to enable 2 WAY SSL with “authenticate
> Peer” flag set to TRUE.
> Restart the qdrouterd instance to pick up the config changes.
> Make the client send a message based on the AMQP-CLIENT library (which uses
> Proton J).
> Client Error Message: from the log file
> AMQP framing error
> EventImpl{type=TRANSPORT_ERROR, context=TransportImpl
> [_connectionEndpoint=org.apache.qpid.proton.engine.impl.ConnectionImpl@6ef351a0,
> org.apache.qpid.proton.engine.impl.TransportImpl@44c213d9]}
> Server Error Message: from the log file
> =64, totalFreeToHeap=0, transferBatchSize=64,
> type=org.apache.qpid.dispatch.allocator, typeName=qd_timer_t, typeSize=56)
> Wed Mar 30 12:00:47 2016 AGENT (info) Activating management agent on
> $management
> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address Registered:
> $management
> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address Registered:
> $management
> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
> FixedAddressEntity(bias=closest, fanout=single, identity=fixedAddress/0,
> name=fixedAddress/0, prefix=/, type=org.apache.qpid.dispatch.fixedAddress)
> Wed Mar 30 12:00:47 2016 ROUTER (info) Configured Address: prefix=/ phase=0
> fanout=QD_SCHEMA_FIXEDADDRESS_FANOUT_SINGLE
> bias=QD_SCHEMA_FIXEDADDRESS_BIAS_CLOSEST
> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
> ListenerEntity(addr=0.0.0.0, authenticatePeer=True,
> certDb=/home/vsharda/protected/pprootca_cert.pem,
> certFile=/home/vsharda/protected/generic_cert.pem,
> identity=listener/0.0.0.0:20009, idleTimeoutSeconds=16,
> keyFile=/home/vsharda/protected/generic_key.pem, maxFrameSize=65536,
> name=listener/0.0.0.0:20009, password=pn2.GmdXmkKv.X7fPq.oYDFj8Cs,
> port=20009, requireEncryption=True, requireSsl=True, role=normal,
> saslMechanisms=EXTERNAL, stripAnnotations=both,
> type=org.apache.qpid.dispatch.listener)
> Wed Mar 30 12:00:47 2016 CONN_MGR (info) Configured Listener: 0.0.0.0:20009
> proto=any role=normal
> Wed Mar 30 12:00:47 2016 SERVER (trace) Listening on 0.0.0.0:20009
> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
> ConsoleEntity(identity=console/0, name=console/0,
> type=org.apache.qpid.dispatch.console, wsport=5673)
> Wed Mar 30 12:00:47 2016 SERVER (info) Operational, 4 Threads Running
> Wed Mar 30 12:01:06 2016 SERVER (debug) Accepting incoming connection from
> 10.225.90.106:51196 to 0.0.0.0:20009
> Wed Mar 30 12:01:06 2016 SERVER (trace) Configuring SSL on incoming
> connection from 10.225.90.106:51196 to 0.0.0.0:20009
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Server SSL socket created.
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:SSL/TLS connection detected
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl( data size=162 )
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Wrote 162 bytes to BIO Layer, 0
> left over
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Detected read-blocked
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl() returning 162
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Read 3651 bytes from BIO Layer
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl() returning
> 3651
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl() returning 0
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl() returning 0
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl() returning 0
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl() returning 0
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl( data size=205 )
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Wrote 205 bytes to BIO Layer, 0
> left over
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:ERROR
> amqp:connection:framing-error SSL Failure: error:140890C7:SSL
> routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]: <- EOS
> Wed Mar 30 12:01:06 201
[jira] [Resolved] (PROTON-1237) C connection_engine interface and libuv example driver.
[ https://issues.apache.org/jira/browse/PROTON-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1237. - Resolution: Fixed The C engine is completed with a simple libuv client example. Completing a multi-threaded libuv container has been separated to PROTON-1259 > C connection_engine interface and libuv example driver. > --- > > Key: PROTON-1237 > URL: https://issues.apache.org/jira/browse/PROTON-1237 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.12.2 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.14.0 > > > The C++ and Ruby bindings have a connection_engine interface: it gathers > together the functionality of pn_connection pn_transport and pn_collector to > enable handler-style programming against a single connection, with no > assumptions about IO or threading. > Some of this can be back-ported to C to make it easier to do reactive > programming in C without using the pn_reactor (which forces IO and threading > choices on the user) > Create a C version of the C++ io::connection_engine and use it as the > implementation of the C++ and Go binding engines. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1230) cpp_container_example_test fails due to /etc/sasl2/proton-server.conf configuration
[ https://issues.apache.org/jira/browse/PROTON-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1230: Fix Version/s: 0.14.0 > cpp_container_example_test fails due to /etc/sasl2/proton-server.conf > configuration > --- > > Key: PROTON-1230 > URL: https://issues.apache.org/jira/browse/PROTON-1230 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0 >Reporter: Ken Giusti >Assignee: Cliff Jansen > Fix For: 0.14.0 > > > I had an old stale /etc/sasl2/proton-server.conf file lying around that had > set mech_list: ANONYMOUS > This cause the following unit test failure: > test 23 > Start 23: cpp_container_example_test > 23: Test command: /usr/bin/python > "/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/proton-c/env.py" "--" > "PATH=/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/BUILD/examples/cpp:/home/kgiusti/.local/bin:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/kgiusti/bin:/opt/coverity/bin" > "VALGRIND=/usr/bin/valgrind" "/usr/bin/python" > "/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/examples/cpp/example_test.py" > "-v" "ContainerExampleTest" > 23: Test timeout computed to be: 1500 > 23: test_encode_decode (__main__.ContainerExampleTest) ... ok > 23: test_flow_control (__main__.ContainerExampleTest) ... ok > 23: test_helloworld (__main__.ContainerExampleTest) ... ok > 23: test_helloworld_direct (__main__.ContainerExampleTest) ... ok > 23: test_request_response (__main__.ContainerExampleTest) ... ok > 23: test_request_response_direct (__main__.ContainerExampleTest) ... ok > 23: test_simple_recv_direct_send (__main__.ContainerExampleTest) ... ok > 23: test_simple_recv_send (__main__.ContainerExampleTest) ... ok > 23: test_simple_send_direct_recv (__main__.ContainerExampleTest) ... ok > 23: test_simple_send_recv (__main__.ContainerExampleTest) ... ok > 23: test_ssl (__main__.ContainerExampleTest) ... ok > 23: test_ssl_client_cert (__main__.ContainerExampleTest) ... ERROR > 23: > 23: == > 23: ERROR: test_ssl_client_cert (__main__.ContainerExampleTest) > 23: -- > 23: Traceback (most recent call last): > 23: File > "/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/examples/cpp/example_test.py", > line 320, in test_ssl_client_cert > 23: out = self.proc(["ssl_client_cert", addr, self.ssl_certs_dir()], > skip_valgrind=True).wait_exit() > 23: File > "/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/examples/cpp/example_test.py", > line 128, in wait_exit > 23: self.check_() > 23: File > "/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/examples/cpp/example_test.py", > line 93, in run_ > 23: raise ProcError(self) > 23: ProcError: ['ssl_client_cert', 'amqps://127.0.0.1:16333/examples', > '/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/examples/cpp/ssl_certs'] > non-0 exit, code=1 > 23: > 23: amqp:unauthorized-access: Authentication failed [mech=(null)] > 23: > 23: > 23: > 23: -- > 23: Ran 12 tests in 10.584s > 23: > 23: FAILED (errors=1) > The tests should be set up so that they are not influenced by the system's > native configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1237) C connection_engine interface and libuv example driver.
[ https://issues.apache.org/jira/browse/PROTON-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-1237: Description: The C++ and Ruby bindings have a connection_engine interface: it gathers together the functionality of pn_connection pn_transport and pn_collector to enable handler-style programming against a single connection, with no assumptions about IO or threading. Some of this can be back-ported to C to make it easier to do reactive programming in C without using the pn_reactor (which forces IO and threading choices on the user) Create a C version of the C++ io::connection_engine and use it as the implementation of the C++ and Go binding engines. was: The C++ and Ruby bindings have a connection_engine interface: it gathers together the functionality of pn_connection pn_transport and pn_collector to enable handler-style programming against a single connection, with no assumptions about IO or threading. Some of this can be back-ported to C to make it easier to do reactive programming in C without using the pn_reactor (which forces IO and threading choices on the user) To validate the work, add a single-threaded C example using the libuv library for IO, and a multi-threaded C++ proton::container implementation also built on libuv. > C connection_engine interface and libuv example driver. > --- > > Key: PROTON-1237 > URL: https://issues.apache.org/jira/browse/PROTON-1237 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.12.2 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.14.0 > > > The C++ and Ruby bindings have a connection_engine interface: it gathers > together the functionality of pn_connection pn_transport and pn_collector to > enable handler-style programming against a single connection, with no > assumptions about IO or threading. > Some of this can be back-ported to C to make it easier to do reactive > programming in C without using the pn_reactor (which forces IO and threading > choices on the user) > Create a C version of the C++ io::connection_engine and use it as the > implementation of the C++ and Go binding engines. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1230) cpp_container_example_test fails due to /etc/sasl2/proton-server.conf configuration
[ https://issues.apache.org/jira/browse/PROTON-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1230: Priority: Major (was: Minor) > cpp_container_example_test fails due to /etc/sasl2/proton-server.conf > configuration > --- > > Key: PROTON-1230 > URL: https://issues.apache.org/jira/browse/PROTON-1230 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0 >Reporter: Ken Giusti >Assignee: Cliff Jansen > > I had an old stale /etc/sasl2/proton-server.conf file lying around that had > set mech_list: ANONYMOUS > This cause the following unit test failure: > test 23 > Start 23: cpp_container_example_test > 23: Test command: /usr/bin/python > "/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/proton-c/env.py" "--" > "PATH=/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/BUILD/examples/cpp:/home/kgiusti/.local/bin:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/kgiusti/bin:/opt/coverity/bin" > "VALGRIND=/usr/bin/valgrind" "/usr/bin/python" > "/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/examples/cpp/example_test.py" > "-v" "ContainerExampleTest" > 23: Test timeout computed to be: 1500 > 23: test_encode_decode (__main__.ContainerExampleTest) ... ok > 23: test_flow_control (__main__.ContainerExampleTest) ... ok > 23: test_helloworld (__main__.ContainerExampleTest) ... ok > 23: test_helloworld_direct (__main__.ContainerExampleTest) ... ok > 23: test_request_response (__main__.ContainerExampleTest) ... ok > 23: test_request_response_direct (__main__.ContainerExampleTest) ... ok > 23: test_simple_recv_direct_send (__main__.ContainerExampleTest) ... ok > 23: test_simple_recv_send (__main__.ContainerExampleTest) ... ok > 23: test_simple_send_direct_recv (__main__.ContainerExampleTest) ... ok > 23: test_simple_send_recv (__main__.ContainerExampleTest) ... ok > 23: test_ssl (__main__.ContainerExampleTest) ... ok > 23: test_ssl_client_cert (__main__.ContainerExampleTest) ... ERROR > 23: > 23: == > 23: ERROR: test_ssl_client_cert (__main__.ContainerExampleTest) > 23: -- > 23: Traceback (most recent call last): > 23: File > "/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/examples/cpp/example_test.py", > line 320, in test_ssl_client_cert > 23: out = self.proc(["ssl_client_cert", addr, self.ssl_certs_dir()], > skip_valgrind=True).wait_exit() > 23: File > "/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/examples/cpp/example_test.py", > line 128, in wait_exit > 23: self.check_() > 23: File > "/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/examples/cpp/example_test.py", > line 93, in run_ > 23: raise ProcError(self) > 23: ProcError: ['ssl_client_cert', 'amqps://127.0.0.1:16333/examples', > '/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/examples/cpp/ssl_certs'] > non-0 exit, code=1 > 23: > 23: amqp:unauthorized-access: Authentication failed [mech=(null)] > 23: > 23: > 23: > 23: -- > 23: Ran 12 tests in 10.584s > 23: > 23: FAILED (errors=1) > The tests should be set up so that they are not influenced by the system's > native configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1230) cpp_container_example_test fails due to /etc/sasl2/proton-server.conf configuration
[ https://issues.apache.org/jira/browse/PROTON-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1230: Fix Version/s: (was: 0.14.0) > cpp_container_example_test fails due to /etc/sasl2/proton-server.conf > configuration > --- > > Key: PROTON-1230 > URL: https://issues.apache.org/jira/browse/PROTON-1230 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0 >Reporter: Ken Giusti >Assignee: Cliff Jansen > > I had an old stale /etc/sasl2/proton-server.conf file lying around that had > set mech_list: ANONYMOUS > This cause the following unit test failure: > test 23 > Start 23: cpp_container_example_test > 23: Test command: /usr/bin/python > "/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/proton-c/env.py" "--" > "PATH=/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/BUILD/examples/cpp:/home/kgiusti/.local/bin:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/kgiusti/bin:/opt/coverity/bin" > "VALGRIND=/usr/bin/valgrind" "/usr/bin/python" > "/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/examples/cpp/example_test.py" > "-v" "ContainerExampleTest" > 23: Test timeout computed to be: 1500 > 23: test_encode_decode (__main__.ContainerExampleTest) ... ok > 23: test_flow_control (__main__.ContainerExampleTest) ... ok > 23: test_helloworld (__main__.ContainerExampleTest) ... ok > 23: test_helloworld_direct (__main__.ContainerExampleTest) ... ok > 23: test_request_response (__main__.ContainerExampleTest) ... ok > 23: test_request_response_direct (__main__.ContainerExampleTest) ... ok > 23: test_simple_recv_direct_send (__main__.ContainerExampleTest) ... ok > 23: test_simple_recv_send (__main__.ContainerExampleTest) ... ok > 23: test_simple_send_direct_recv (__main__.ContainerExampleTest) ... ok > 23: test_simple_send_recv (__main__.ContainerExampleTest) ... ok > 23: test_ssl (__main__.ContainerExampleTest) ... ok > 23: test_ssl_client_cert (__main__.ContainerExampleTest) ... ERROR > 23: > 23: == > 23: ERROR: test_ssl_client_cert (__main__.ContainerExampleTest) > 23: -- > 23: Traceback (most recent call last): > 23: File > "/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/examples/cpp/example_test.py", > line 320, in test_ssl_client_cert > 23: out = self.proc(["ssl_client_cert", addr, self.ssl_certs_dir()], > skip_valgrind=True).wait_exit() > 23: File > "/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/examples/cpp/example_test.py", > line 128, in wait_exit > 23: self.check_() > 23: File > "/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/examples/cpp/example_test.py", > line 93, in run_ > 23: raise ProcError(self) > 23: ProcError: ['ssl_client_cert', 'amqps://127.0.0.1:16333/examples', > '/home/kgiusti/work/proton/0.13.0/qpid-proton-0.13.0/examples/cpp/ssl_certs'] > non-0 exit, code=1 > 23: > 23: amqp:unauthorized-access: Authentication failed [mech=(null)] > 23: > 23: > 23: > 23: -- > 23: Ran 12 tests in 10.584s > 23: > 23: FAILED (errors=1) > The tests should be set up so that they are not influenced by the system's > native configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1257) c++ cached_map core dump on assignment
[ https://issues.apache.org/jira/browse/PROTON-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1257: Priority: Critical (was: Major) > c++ cached_map core dump on assignment > -- > > Key: PROTON-1257 > URL: https://issues.apache.org/jira/browse/PROTON-1257 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.14.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Critical > Fix For: 0.14.0 > > > The copy created is deleted but the pn_unique_ptr still points to the > released memory. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1259) c: libuv multi-threaded example driver.
[ https://issues.apache.org/jira/browse/PROTON-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-1259: Description: Implement a multi-threaded C++ proton::container implementation also built on libuv. Demonstrate use of the C connection_engine_t to integrate with an external proactive IO library. (was: The C++ and Ruby bindings have a connection_engine interface: it gathers together the functionality of pn_connection pn_transport and pn_collector to enable handler-style programming against a single connection, with no assumptions about IO or threading. Some of this can be back-ported to C to make it easier to do reactive programming in C without using the pn_reactor (which forces IO and threading choices on the user) To validate the work, add a single-threaded C example using the libuv library for IO, and a multi-threaded C++ proton::container implementation also built on libuv. ) > c: libuv multi-threaded example driver. > --- > > Key: PROTON-1259 > URL: https://issues.apache.org/jira/browse/PROTON-1259 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.12.2 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.14.0 > > > Implement a multi-threaded C++ proton::container implementation also built on > libuv. Demonstrate use of the C connection_engine_t to integrate with an > external proactive IO library. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1259) c: libuv multi-threaded example driver.
Alan Conway created PROTON-1259: --- Summary: c: libuv multi-threaded example driver. Key: PROTON-1259 URL: https://issues.apache.org/jira/browse/PROTON-1259 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.12.2 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.14.0 The C++ and Ruby bindings have a connection_engine interface: it gathers together the functionality of pn_connection pn_transport and pn_collector to enable handler-style programming against a single connection, with no assumptions about IO or threading. Some of this can be back-ported to C to make it easier to do reactive programming in C without using the pn_reactor (which forces IO and threading choices on the user) To validate the work, add a single-threaded C example using the libuv library for IO, and a multi-threaded C++ proton::container implementation also built on libuv. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1243) Calling proton::container::stop() from within event handler causes infinite recursion
[
https://issues.apache.org/jira/browse/PROTON-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1243:
Fix Version/s: (was: 0.14.0)
> Calling proton::container::stop() from within event handler causes infinite
> recursion
> -
>
> Key: PROTON-1243
> URL: https://issues.apache.org/jira/browse/PROTON-1243
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding, proton-c
>Affects Versions: 0.13.0
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>
> There is current way to use proton::container::stop() or pn_reactor_stop()
> from within an event handler without causing infinite recursion.
> Indeed there is even a note inside pn_reactor_stop():
> {noformat}
> ...
> // XXX: should consider removing this from stop to avoid reentrance
> pn_reactor_process(reactor);
> ...
> {noformat}
> So I think there is no way to fix the issue in the current C++ implementation
> without removing the recursion somehow from the C code. However I don't know
> if doing this will cause a bug in some other circumstances!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1165) qpid proton cpp binding posix/io.cpp tests wrong error condition
[
https://issues.apache.org/jira/browse/PROTON-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1165:
Assignee: Alan Conway (was: Cliff Jansen)
> qpid proton cpp binding posix/io.cpp tests wrong error condition
>
>
> Key: PROTON-1165
> URL: https://issues.apache.org/jira/browse/PROTON-1165
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.12.0
> Environment: linux/posix
>Reporter: Roman Puls
>Assignee: Alan Conway
> Labels: patch
> Fix For: 0.14.0
>
>
> posix/io.cpp:
> size_t socket_engine::io_write(const char *buf, size_t size) {
> ssize_t n = ::write(socket_, buf, size);
> if (n == EAGAIN || n == EWOULDBLOCK) return 0;
> if (n < 0) check(n, "write: ");
> return n;
> }
> instead of testing n against EAGAIN/EWOULDBLOCK, n needs to be tested against
> -1 and then errno needs to be compared to EAGAIN/EWOULDBLOCK
> proposed fix:
> size_t socket_engine::io_write(const char *buf, size_t size) {
> ssize_t n = ::write(socket_, buf, size);
> if (n < 0) {
> if (errno == EAGAIN || errno == EWOULDBLOCK) {
> return 0;
> }
> check(n, "write: ");
> }
> return n;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-852) Implement pn_getaddrinfo,pn_getprotobyname for platforms that not support getaddrinfo(),getprotobyname()
[ https://issues.apache.org/jira/browse/PROTON-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-852: --- Fix Version/s: (was: 0.14.0) 0.15.0 > Implement pn_getaddrinfo,pn_getprotobyname for platforms that not support > getaddrinfo(),getprotobyname() > - > > Key: PROTON-852 > URL: https://issues.apache.org/jira/browse/PROTON-852 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.9, 0.9.1, 0.10 > Environment: uclinux m68k >Reporter: Tomasz Nowicki >Assignee: Andrew Stitcher > Labels: patch > Fix For: 0.15.0 > > Attachments: proton-c-GETADDRINFO.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > We are using proton-c on a small ebedded system based on uclinux/uclibc.c On > this platform several required functions ex getaddrinfo(), getprotobyname() > are not implemented.We added support for this type of platform by wraping > with pn_getaddrinfo,pn_getprotobyname. Relevant pn_freeaddrinfo is also > introduced. If GETADDRINFO_NOT_IMPL flag is not present, native > implementation is called. Changes apply for posix versions that use old lib.c > Specifically in some embedded versions "get host" is not present(ip address > is used instead). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-486) Create a User's Guide
[ https://issues.apache.org/jira/browse/PROTON-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-486: --- Fix Version/s: (was: 0.14.0) > Create a User's Guide > - > > Key: PROTON-486 > URL: https://issues.apache.org/jira/browse/PROTON-486 > Project: Qpid Proton > Issue Type: Improvement >Reporter: Andreas Mueller >Assignee: Justin Ross > > What would really helpful is a one-page user guide where you explain the > Messenger API. I want to know e.g. how to use the different QoS exactly-once, > at-most-once, at-least-once and all that stuff I can do with that API without > jumping from one header file to another and need to ask questions in mailing > lists. Provide basic samples with snippets in the different supported > language bindings. > I think Messenger API is quite comparable with SwiftMQ's AMQP 1.0 Client. > This is how our client is documented: > http://www.swiftmq.com/products/router/swiftlets/sys_amqp/client/index.html > That's it. Doesn't took much effort to create it. > Proton is *the* standard AMQP 1.0 driver. It would be a shame if users went > frustrated away from it because they don't understand the basic concepts. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1177) [proton-j] Source and Target interfaces are incomplete and confusing
[ https://issues.apache.org/jira/browse/PROTON-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1177: Fix Version/s: (was: 0.14.0) 0.15.0 > [proton-j] Source and Target interfaces are incomplete and confusing > > > Key: PROTON-1177 > URL: https://issues.apache.org/jira/browse/PROTON-1177 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.12.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.15.0 > > > The org.apache.qpid.proton.amqp.transport.Source and > org.apache.qpid.proton.amqp.transport.Target interfaces are used on the Link > interface setters/getters, however they container almost none of the methods > needed to use the Source and Target. The impls have all the necessary > methods, but folks would currently need to cast the values to them in order > to use in almost any meaningful way, and they exist in a completely different > package which makes them less than obvious. Finally, most of the interfaces > for engine objects have a factory in their interface for creating them, the > Source and Target ones do not, making their use less obvious again. > Changing the existing interface/impl names/packages would break most existing > uses, so we probably want to avoid that, but we should at least update the > interfaces to contain the required methods, and perhaps add the equivalent > factories to make their creation more obvious. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1257) c++ cached_map core dump on assignment
[ https://issues.apache.org/jira/browse/PROTON-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1257: Fix Version/s: 0.14.0 > c++ cached_map core dump on assignment > -- > > Key: PROTON-1257 > URL: https://issues.apache.org/jira/browse/PROTON-1257 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.14.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.14.0 > > > The copy created is deleted but the pn_unique_ptr still points to the > released memory. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1140) [proton-c] Always set process name and process id as connection properties
[ https://issues.apache.org/jira/browse/PROTON-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1140: Summary: [proton-c] Always set process name and process id as connection properties (was: [proton-c] Always set process name and process id as message properties ) > [proton-c] Always set process name and process id as connection properties > --- > > Key: PROTON-1140 > URL: https://issues.apache.org/jira/browse/PROTON-1140 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.12.0 >Reporter: Ganesh Murthy >Priority: Minor > > The connection initiating peer must set message properties of process name > and process id. The receiving peer will be able to access these properties > using pn_connection_remote_properties(connection) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1179) [C++ binding] Rework condition class
[ https://issues.apache.org/jira/browse/PROTON-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379456#comment-15379456 ] Andrew Stitcher commented on PROTON-1179: - I'm not sure that the property part of condition works yet, now that the value_ref code is there it should be straightforward if not. > [C++ binding] Rework condition class > > > Key: PROTON-1179 > URL: https://issues.apache.org/jira/browse/PROTON-1179 > Project: Qpid Proton > Issue Type: Improvement >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > > * Rename condition to error_condition > * rename info member to properties > * change it from a pure wrapper of pn_condition_t to be a value type. > ** privately constructed from a pn_condition_t > ** API constructed from name [description [properties] ] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1238) There is no way to query proton::connection for the url it was created with.
[ https://issues.apache.org/jira/browse/PROTON-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1238: Fix Version/s: 0.14.0 > There is no way to query proton::connection for the url it was created with. > > > Key: PROTON-1238 > URL: https://issues.apache.org/jira/browse/PROTON-1238 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.14.0 > > > Although the user could just remember whatever url they used to create a > given connection, it is duplicative when the library has the info around. > Also if it is not provided then the user has to plumb to info to places it is > needed inside the event handlers, however the handlers will already get the > connection context object anyway so that is unecessary and an extra burden. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1241) proton::messaging_handler is not copyable (because it contains a pn_unique_ptr)
[
https://issues.apache.org/jira/browse/PROTON-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1241:
Fix Version/s: 0.14.0
> proton::messaging_handler is not copyable (because it contains a
> pn_unique_ptr)
> ---
>
> Key: PROTON-1241
> URL: https://issues.apache.org/jira/browse/PROTON-1241
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Cliff Jansen
> Fix For: 0.14.0
>
>
> One fundamental of the Proton C++ API is that the user supplies their own
> handler class.
> We should strive in our implementation to limit the API user as little as
> possible. Unfortunately , because of some historical implementation decisions
> the messaging_handler class contains a single member which is not copyable
> (this is a unique_ptr to the associated internal messaging_adapter).
> This stops the user being able to natural things with her own classes like:
> {noformat}
> class MyHandler: public messaging_handler {
> ...
> }
> ...
> auto h = MyHandler{};
> ...
> Myhandler g;
> auto i = g;
> {noformat}
> The user knows what she wants to do with her classes and there is no real
> intrinsic requirement for the messaging_handler to keep hold of a
> messaging_adapter. So we need to get out of the users way and remove the
> pn_unique_ptr from messaging_handler.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1243) Calling proton::container::stop() from within event handler causes infinite recursion
[
https://issues.apache.org/jira/browse/PROTON-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1243:
Fix Version/s: 0.14.0
> Calling proton::container::stop() from within event handler causes infinite
> recursion
> -
>
> Key: PROTON-1243
> URL: https://issues.apache.org/jira/browse/PROTON-1243
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding, proton-c
>Affects Versions: 0.13.0
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.14.0
>
>
> There is current way to use proton::container::stop() or pn_reactor_stop()
> from within an event handler without causing infinite recursion.
> Indeed there is even a note inside pn_reactor_stop():
> {noformat}
> ...
> // XXX: should consider removing this from stop to avoid reentrance
> pn_reactor_process(reactor);
> ...
> {noformat}
> So I think there is no way to fix the issue in the current C++ implementation
> without removing the recursion somehow from the C code. However I don't know
> if doing this will cause a bug in some other circumstances!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1166) installer forgets to install io subfolder of includes
[ https://issues.apache.org/jira/browse/PROTON-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1166: Fix Version/s: 0.14.0 > installer forgets to install io subfolder of includes > - > > Key: PROTON-1166 > URL: https://issues.apache.org/jira/browse/PROTON-1166 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0 >Reporter: Roman Puls >Assignee: Cliff Jansen >Priority: Trivial > Fix For: 0.14.0 > > > I just installed qpid HEAD-45390a9, and currently the install script does not > copy over the io folder from the includes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1244) Add user & password connection_options
[ https://issues.apache.org/jira/browse/PROTON-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1244: Fix Version/s: 0.14.0 > Add user & password connection_options > -- > > Key: PROTON-1244 > URL: https://issues.apache.org/jira/browse/PROTON-1244 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.14.0 > > > It would be useful if we could a set connection authentication aside from the > textual URL used to specify the connection address. > I propose that we add > * connection_options::user(const std::tring&) > * connection_options::password(const std::string&) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1165) qpid proton cpp binding posix/io.cpp tests wrong error condition
[
https://issues.apache.org/jira/browse/PROTON-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1165:
Fix Version/s: 0.14.0
> qpid proton cpp binding posix/io.cpp tests wrong error condition
>
>
> Key: PROTON-1165
> URL: https://issues.apache.org/jira/browse/PROTON-1165
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.12.0
> Environment: linux/posix
>Reporter: Roman Puls
>Assignee: Cliff Jansen
> Labels: patch
> Fix For: 0.14.0
>
>
> posix/io.cpp:
> size_t socket_engine::io_write(const char *buf, size_t size) {
> ssize_t n = ::write(socket_, buf, size);
> if (n == EAGAIN || n == EWOULDBLOCK) return 0;
> if (n < 0) check(n, "write: ");
> return n;
> }
> instead of testing n against EAGAIN/EWOULDBLOCK, n needs to be tested against
> -1 and then errno needs to be compared to EAGAIN/EWOULDBLOCK
> proposed fix:
> size_t socket_engine::io_write(const char *buf, size_t size) {
> ssize_t n = ::write(socket_, buf, size);
> if (n < 0) {
> if (errno == EAGAIN || errno == EWOULDBLOCK) {
> return 0;
> }
> check(n, "write: ");
> }
> return n;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1179) [C++ binding] Rework condition class
[ https://issues.apache.org/jira/browse/PROTON-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379446#comment-15379446 ] Justin Ross commented on PROTON-1179: - [~astitcher], is this one done? > [C++ binding] Rework condition class > > > Key: PROTON-1179 > URL: https://issues.apache.org/jira/browse/PROTON-1179 > Project: Qpid Proton > Issue Type: Improvement >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > > * Rename condition to error_condition > * rename info member to properties > * change it from a pure wrapper of pn_condition_t to be a value type. > ** privately constructed from a pn_condition_t > ** API constructed from name [description [properties] ] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1250) 0.13.1 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-1250. --- Resolution: Done http://qpid.apache.org/releases/qpid-proton-0.13.1/ > 0.13.1 release tasks > > > Key: PROTON-1250 > URL: https://issues.apache.org/jira/browse/PROTON-1250 > Project: Qpid Proton > Issue Type: Task > Components: release >Reporter: Justin Ross >Assignee: Justin Ross > Fix For: 0.13.1 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-437) Reconcile C and python management agents
[ https://issues.apache.org/jira/browse/DISPATCH-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated DISPATCH-437: - Assignee: Ganesh Murthy (was: Ted Ross) > Reconcile C and python management agents > > > Key: DISPATCH-437 > URL: https://issues.apache.org/jira/browse/DISPATCH-437 > Project: Qpid Dispatch > Issue Type: Bug > Components: Management Agent >Affects Versions: 0.6.0 >Reporter: Alan Conway >Assignee: Ganesh Murthy > > The router now has two management agents, one in C and one in Python. They > have overlapping and inconsistent functionality, which creates a difficult > user experience. They need to be more closely aligned. > Issues noted so far: > - python agent "identity" attribute is unique per-agent. C agent "identity" > is only unique per type and cannot be used in READ requests (DISPATCH-409) > - python agent allows delete by name or identity alone, C agent requires the > client specify the type as well (DISPATCH-408) > - C agent does not do string conversions for integral attribute types as > reqiured by the management spec. The "fix" in qdmanage is incorrect > (DISPATCH-411) > - There are two address types - > org.apache.qpid.dispatch.router.config.address and > org.apache.qpid.dispatch.router.address. There is no shortname for > org.apache.qpid.dispatch.router.address. Should short names be removed ? > I recommend that we need: > 1. A single code path to validate/convert/insert defaults in incoming > requests based on the schema. > 2. A clear, documented statement of what "identity" means and whether it is > type-scoped or agent-scoped, with a re-implementation of either the C or > python entities to comply. > We may need to rework the interface between python and C to make it efficient > and thread-safe, or refactor some/all of the python functionality as C, but > we do need to get rid of the redundancy and inconsistency. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7331) [Java Broker] Preference Store JSON backend
[ https://issues.apache.org/jira/browse/QPID-7331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379344#comment-15379344 ] Keith Wall commented on QPID-7331: -- The last commit was intended for QPID-7247. > [Java Broker] Preference Store JSON backend > --- > > Key: QPID-7331 > URL: https://issues.apache.org/jira/browse/QPID-7331 > Project: Qpid > Issue Type: New Feature > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-6.1 > > > Implement a JSON backend to the PreferenceStore > see also QPID-7330 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7247) Implement preferences model and REST API
[ https://issues.apache.org/jira/browse/QPID-7247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379346#comment-15379346 ] Keith Wall commented on QPID-7247: -- The following commit was intended for this JIRA: Commit 1752836 from Keith Wall in branch 'java/trunk' [ https://svn.apache.org/r1752836 ] QPID-7331: [Java Broker] Query preferences - do not persist offset, limit etc Reply > Implement preferences model and REST API > > > Key: QPID-7247 > URL: https://issues.apache.org/jira/browse/QPID-7247 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Lorenz Quack > Fix For: qpid-java-6.1 > > > Implement the preferences model and the REST API described by: > https://cwiki.apache.org/confluence/display/qpid/Preference+Store > After this work it will be possible to add/update/remove preference from the > REST API, but there will be no persistence. At this stage all preferences > will be available to all users. There will be no security in preferences > layer. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (QPID-7247) Implement preferences model and REST API
[ https://issues.apache.org/jira/browse/QPID-7247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reopened QPID-7247: -- > Implement preferences model and REST API > > > Key: QPID-7247 > URL: https://issues.apache.org/jira/browse/QPID-7247 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Lorenz Quack > Fix For: qpid-java-6.1 > > > Implement the preferences model and the REST API described by: > https://cwiki.apache.org/confluence/display/qpid/Preference+Store > After this work it will be possible to add/update/remove preference from the > REST API, but there will be no persistence. At this stage all preferences > will be available to all users. There will be no security in preferences > layer. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7331) [Java Broker] Preference Store JSON backend
[ https://issues.apache.org/jira/browse/QPID-7331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379343#comment-15379343 ] ASF subversion and git services commented on QPID-7331: --- Commit 1752836 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1752836 ] QPID-7331: [Java Broker] Query preferences - do not persist offset, limit etc > [Java Broker] Preference Store JSON backend > --- > > Key: QPID-7331 > URL: https://issues.apache.org/jira/browse/QPID-7331 > Project: Qpid > Issue Type: New Feature > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-6.1 > > > Implement a JSON backend to the PreferenceStore > see also QPID-7330 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7318) [Java Broker] Refactor existing ACL plugin code
[ https://issues.apache.org/jira/browse/QPID-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379323#comment-15379323 ] ASF subversion and git services commented on QPID-7318: --- Commit 1752834 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1752834 ] QPID-7318 : Fix NPEs on shutdown > [Java Broker] Refactor existing ACL plugin code > --- > > Key: QPID-7318 > URL: https://issues.apache.org/jira/browse/QPID-7318 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > > While the aim is to redesign the ACL implementation in the v6.2 or v7.0 > timeframe, there is still utility in tidying up the existing ACL > implementation a bit. In particular by separating out functions and > providing a better encapsulation, we will make the job of writing automated > upgraders to any new ACL implementation substantially easier. > As a first step we can separate out the parsing of the ACL file, from the > "rule based" implementation of ACLs. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7248) Extend the UI to allow queries to be saved, retrieved and re-run
[ https://issues.apache.org/jira/browse/QPID-7248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379277#comment-15379277 ] ASF subversion and git services commented on QPID-7248: --- Commit 1752823 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1752823 ] QPID-7248: [Java Broker] Query UI - wire up visibilityList to the authenticated user's groups > Extend the UI to allow queries to be saved, retrieved and re-run > > > Key: QPID-7248 > URL: https://issues.apache.org/jira/browse/QPID-7248 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-6.1 > > Attachments: > 0001-QPID-7248-Java-Broker-Preferences-show-preferences-b.patch, > extend-query-ui-to-allow-queries-to-be-saved.tar.gz, > query-browser-patches.tar.gz > > > Extend the UI to allow the user to save a query so that it is available for > use later on. The user should be able to see a list of saved queries, pick > one and rerun it or change it. The user should be able to delete queries too. > The user should also be able to see queries that are visible to him. He > should be able to select these queries and execute them. > * When defining a query, the UI should offer a 'save as' button allowing the > query to be named, visibility to be chosen, and saved. > * If the query has been saved already, the name should be filled in already. > * Saved queries and queries that are visible to the user will appear to the > user as a list (expandable/collapsible widget) > * From the list the user will be able to delete queries that belong to him. > * Also from the list, the user will be able to recall queries (either queries > that belong to him or ones that are visible). The query will be recalled in > the advanced > view, even if the query is representable in standard view. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7188) [Java Broker] [AMQP1.0] Define a target capability to define how a target will respond when receiving a message it cannot route
[ https://issues.apache.org/jira/browse/QPID-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey reassigned QPID-7188: - Assignee: Rob Godfrey > [Java Broker] [AMQP1.0] Define a target capability to define how a target > will respond when receiving a message it cannot route > --- > > Key: QPID-7188 > URL: https://issues.apache.org/jira/browse/QPID-7188 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-6.1 > > > As per > [this|http://qpid.2158936.n2.nabble.com/Unroutable-messages-in-Java-Qpid-Broker-6-0-0-tp7641320p7641458.html] > discussion on the mailing list, the Java Broker will currently reject a > message sent to an exchange target which it is unable to route to any queues. > We should enhance the broker so that > # There is a configuration parameter on the exchange to allow the behaviour > to be defaulted (reject / silently discard) > # Two [target > capabilities|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-target] > are defined to allow a link to express its preference / state its behaviour > upon establishment. One capability will describe the "reject" policy, one > "discard". The broker should always send the actual policy in use on the > link even if the client did not indicate a preference. > We should also update the documentation on unroutable messages [here| > https://qpid.apache.org/releases/qpid-java-6.0.0/java-broker/book/Java-Broker-Concepts-Exchanges.html#Java-Broker-Concepts-Exchanges-UnroutableMessage] > to cover the AMQP 1.0 case. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7188) [Java Broker] [AMQP1.0] Define a target capability to define how a target will respond when receiving a message it cannot route
[ https://issues.apache.org/jira/browse/QPID-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-7188: -- Status: Reviewable (was: In Progress) > [Java Broker] [AMQP1.0] Define a target capability to define how a target > will respond when receiving a message it cannot route > --- > > Key: QPID-7188 > URL: https://issues.apache.org/jira/browse/QPID-7188 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-6.1 > > > As per > [this|http://qpid.2158936.n2.nabble.com/Unroutable-messages-in-Java-Qpid-Broker-6-0-0-tp7641320p7641458.html] > discussion on the mailing list, the Java Broker will currently reject a > message sent to an exchange target which it is unable to route to any queues. > We should enhance the broker so that > # There is a configuration parameter on the exchange to allow the behaviour > to be defaulted (reject / silently discard) > # Two [target > capabilities|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-target] > are defined to allow a link to express its preference / state its behaviour > upon establishment. One capability will describe the "reject" policy, one > "discard". The broker should always send the actual policy in use on the > link even if the client did not indicate a preference. > We should also update the documentation on unroutable messages [here| > https://qpid.apache.org/releases/qpid-java-6.0.0/java-broker/book/Java-Broker-Concepts-Exchanges.html#Java-Broker-Concepts-Exchanges-UnroutableMessage] > to cover the AMQP 1.0 case. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7188) [Java Broker] [AMQP1.0] Define a target capability to define how a target will respond when receiving a message it cannot route
[ https://issues.apache.org/jira/browse/QPID-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey reassigned QPID-7188: - Assignee: Keith Wall (was: Rob Godfrey) > [Java Broker] [AMQP1.0] Define a target capability to define how a target > will respond when receiving a message it cannot route > --- > > Key: QPID-7188 > URL: https://issues.apache.org/jira/browse/QPID-7188 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Keith Wall > Fix For: qpid-java-6.1 > > > As per > [this|http://qpid.2158936.n2.nabble.com/Unroutable-messages-in-Java-Qpid-Broker-6-0-0-tp7641320p7641458.html] > discussion on the mailing list, the Java Broker will currently reject a > message sent to an exchange target which it is unable to route to any queues. > We should enhance the broker so that > # There is a configuration parameter on the exchange to allow the behaviour > to be defaulted (reject / silently discard) > # Two [target > capabilities|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-target] > are defined to allow a link to express its preference / state its behaviour > upon establishment. One capability will describe the "reject" policy, one > "discard". The broker should always send the actual policy in use on the > link even if the client did not indicate a preference. > We should also update the documentation on unroutable messages [here| > https://qpid.apache.org/releases/qpid-java-6.0.0/java-broker/book/Java-Broker-Concepts-Exchanges.html#Java-Broker-Concepts-Exchanges-UnroutableMessage] > to cover the AMQP 1.0 case. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7188) [Java Broker] [AMQP1.0] Define a target capability to define how a target will respond when receiving a message it cannot route
[ https://issues.apache.org/jira/browse/QPID-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379231#comment-15379231 ] ASF subversion and git services commented on QPID-7188: --- Commit 1752820 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1752820 ] QPID-7188 : update docs on unroutable message handling > [Java Broker] [AMQP1.0] Define a target capability to define how a target > will respond when receiving a message it cannot route > --- > > Key: QPID-7188 > URL: https://issues.apache.org/jira/browse/QPID-7188 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey > Fix For: qpid-java-6.1 > > > As per > [this|http://qpid.2158936.n2.nabble.com/Unroutable-messages-in-Java-Qpid-Broker-6-0-0-tp7641320p7641458.html] > discussion on the mailing list, the Java Broker will currently reject a > message sent to an exchange target which it is unable to route to any queues. > We should enhance the broker so that > # There is a configuration parameter on the exchange to allow the behaviour > to be defaulted (reject / silently discard) > # Two [target > capabilities|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-target] > are defined to allow a link to express its preference / state its behaviour > upon establishment. One capability will describe the "reject" policy, one > "discard". The broker should always send the actual policy in use on the > link even if the client did not indicate a preference. > We should also update the documentation on unroutable messages [here| > https://qpid.apache.org/releases/qpid-java-6.0.0/java-broker/book/Java-Broker-Concepts-Exchanges.html#Java-Broker-Concepts-Exchanges-UnroutableMessage] > to cover the AMQP 1.0 case. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7188) [Java Broker] [AMQP1.0] Define a target capability to define how a target will respond when receiving a message it cannot route
[ https://issues.apache.org/jira/browse/QPID-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379223#comment-15379223 ] ASF subversion and git services commented on QPID-7188: --- Commit 1752819 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1752819 ] QPID-7188 : Add target capabilities for AMQP 1.0 Destinations that map to Exchanges to allow the selection of either "discard unroutable" or "reject unroutable" behaviours > [Java Broker] [AMQP1.0] Define a target capability to define how a target > will respond when receiving a message it cannot route > --- > > Key: QPID-7188 > URL: https://issues.apache.org/jira/browse/QPID-7188 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey > Fix For: qpid-java-6.1 > > > As per > [this|http://qpid.2158936.n2.nabble.com/Unroutable-messages-in-Java-Qpid-Broker-6-0-0-tp7641320p7641458.html] > discussion on the mailing list, the Java Broker will currently reject a > message sent to an exchange target which it is unable to route to any queues. > We should enhance the broker so that > # There is a configuration parameter on the exchange to allow the behaviour > to be defaulted (reject / silently discard) > # Two [target > capabilities|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-target] > are defined to allow a link to express its preference / state its behaviour > upon establishment. One capability will describe the "reject" policy, one > "discard". The broker should always send the actual policy in use on the > link even if the client did not indicate a preference. > We should also update the documentation on unroutable messages [here| > https://qpid.apache.org/releases/qpid-java-6.0.0/java-broker/book/Java-Broker-Concepts-Exchanges.html#Java-Broker-Concepts-Exchanges-UnroutableMessage] > to cover the AMQP 1.0 case. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Qpid JMS client with Custom SSLContext
Hi, I am trying to connect to the ActiveMq broker with the Qpid amqp client over SSL and set custom SSLContext to it. I cannot find any method as to where this SSLContext can be set. Please help as how this can be done. Regards Tejasvi
[jira] [Updated] (QPID-7303) [Java Broker] Add operation returning the authenticated user principal and groups
[ https://issues.apache.org/jira/browse/QPID-7303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7303: - Assignee: Lorenz Quack (was: Keith Wall) > [Java Broker] Add operation returning the authenticated user principal and > groups > - > > Key: QPID-7303 > URL: https://issues.apache.org/jira/browse/QPID-7303 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Lorenz Quack > Fix For: qpid-java-6.1 > > Attachments: 0001-Add-Whoami-servlet.patch > > > Information about authenticated user groups should be available to the user > via special REST service. > These new REST API is required for implementation of query and dashboard > sharing functionality: user should be able to share queries/dashboards among > groups he/she belongs to. > AP I should provide information about logged user (who am I): > * name > * groups > * it can be extended later to provide moreuser details -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7303) [Java Broker] Add operation returning the authenticated user principal and groups
[ https://issues.apache.org/jira/browse/QPID-7303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7303: - Status: Reviewable (was: In Progress) > [Java Broker] Add operation returning the authenticated user principal and > groups > - > > Key: QPID-7303 > URL: https://issues.apache.org/jira/browse/QPID-7303 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Keith Wall > Fix For: qpid-java-6.1 > > Attachments: 0001-Add-Whoami-servlet.patch > > > Information about authenticated user groups should be available to the user > via special REST service. > These new REST API is required for implementation of query and dashboard > sharing functionality: user should be able to share queries/dashboards among > groups he/she belongs to. > AP I should provide information about logged user (who am I): > * name > * groups > * it can be extended later to provide moreuser details -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7303) [Java Broker] Add operation returning the authenticated user principal and groups
[ https://issues.apache.org/jira/browse/QPID-7303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379163#comment-15379163 ] ASF subversion and git services commented on QPID-7303: --- Commit 1752811 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1752811 ] QPID-7303: [Java Broker] Add Broker operations returning the current authenticated princiapl and groups to which the user belongs. > [Java Broker] Add operation returning the authenticated user principal and > groups > - > > Key: QPID-7303 > URL: https://issues.apache.org/jira/browse/QPID-7303 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Keith Wall > Fix For: qpid-java-6.1 > > Attachments: 0001-Add-Whoami-servlet.patch > > > Information about authenticated user groups should be available to the user > via special REST service. > These new REST API is required for implementation of query and dashboard > sharing functionality: user should be able to share queries/dashboards among > groups he/she belongs to. > AP I should provide information about logged user (who am I): > * name > * groups > * it can be extended later to provide moreuser details -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-7329) [AMQP 1.0]: support message-annotations field for MODIFIED outcome
[ https://issues.apache.org/jira/browse/QPID-7329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed QPID-7329. Resolution: Fixed > [AMQP 1.0]: support message-annotations field for MODIFIED outcome > -- > > Key: QPID-7329 > URL: https://issues.apache.org/jira/browse/QPID-7329 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: qpid-cpp-next > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7351) Wrong Frame after connection openend.
[ https://issues.apache.org/jira/browse/QPID-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379129#comment-15379129 ] Gordon Sim commented on QPID-7351: -- What SASL mechanism is being used? > Wrong Frame after connection openend. > - > > Key: QPID-7351 > URL: https://issues.apache.org/jira/browse/QPID-7351 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Affects Versions: qpid-cpp-0.34 > Environment: Linux its-g5-build-box 3.16.0-4-686-pae #1 SMP Debian > 3.16.7-ckt25-2+deb8u3 (2016-07-02) i686 GNU/Linux > CMake log with all versions attached. >Reporter: Andreas Neustifter >Priority: Minor > Attachments: qpid-cpp-0.34-strange-connection-close.png, > qpid-cpp-0.34.cmake.log > > > I'm using qpid-cpp-0.34 (selfcompiled with SSL support) on a Debian Jessie > 8.4 (latest updates) box. > I'm opening a connection to a AMQP server and everything is fine until the > connection is used. I have a minimal test case where I just open the > connection and close it again. Attached a wireshark screenshot (can't divulge > more) with the offending error. > (The server is confirmed working with qpid-python-0.32, the trace looks fine > there.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1236) Reactor - segfault if connection address cannot be resolved
[
https://issues.apache.org/jira/browse/PROTON-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1236:
Fix Version/s: (was: 0.14.0)
> Reactor - segfault if connection address cannot be resolved
> ---
>
> Key: PROTON-1236
> URL: https://issues.apache.org/jira/browse/PROTON-1236
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.13.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Critical
> Fix For: 0.13.1
>
>
> $ cd examples/python/reactor/send.py
> $ python ./send.py lolhost:/foo
> Segmentation fault (core dumped)
> Same action using 0.12.2 release:
> $ python ./send.py lolhost:/foo
> Condition('proton:io', 'getaddrinfo(lolhost, /amq.topic): Servname not
> supported for ai_socktype')
> $
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1236) Reactor - segfault if connection address cannot be resolved
[
https://issues.apache.org/jira/browse/PROTON-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross closed PROTON-1236.
---
Resolution: Fixed
> Reactor - segfault if connection address cannot be resolved
> ---
>
> Key: PROTON-1236
> URL: https://issues.apache.org/jira/browse/PROTON-1236
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.13.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Critical
> Fix For: 0.13.1
>
>
> $ cd examples/python/reactor/send.py
> $ python ./send.py lolhost:/foo
> Segmentation fault (core dumped)
> Same action using 0.12.2 release:
> $ python ./send.py lolhost:/foo
> Condition('proton:io', 'getaddrinfo(lolhost, /amq.topic): Servname not
> supported for ai_socktype')
> $
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (PROTON-1236) Reactor - segfault if connection address cannot be resolved
[
https://issues.apache.org/jira/browse/PROTON-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross reopened PROTON-1236:
-
> Reactor - segfault if connection address cannot be resolved
> ---
>
> Key: PROTON-1236
> URL: https://issues.apache.org/jira/browse/PROTON-1236
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.13.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Critical
> Fix For: 0.14.0, 0.13.1
>
>
> $ cd examples/python/reactor/send.py
> $ python ./send.py lolhost:/foo
> Segmentation fault (core dumped)
> Same action using 0.12.2 release:
> $ python ./send.py lolhost:/foo
> Condition('proton:io', 'getaddrinfo(lolhost, /amq.topic): Servname not
> supported for ai_socktype')
> $
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7303) [Java Broker] Add operation returning the authenticated user principal and groups
[ https://issues.apache.org/jira/browse/QPID-7303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reassigned QPID-7303: Assignee: Keith Wall > [Java Broker] Add operation returning the authenticated user principal and > groups > - > > Key: QPID-7303 > URL: https://issues.apache.org/jira/browse/QPID-7303 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Keith Wall > Fix For: qpid-java-6.1 > > Attachments: 0001-Add-Whoami-servlet.patch > > > Information about authenticated user groups should be available to the user > via special REST service. > These new REST API is required for implementation of query and dashboard > sharing functionality: user should be able to share queries/dashboards among > groups he/she belongs to. > AP I should provide information about logged user (who am I): > * name > * groups > * it can be extended later to provide moreuser details -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7356) Change default configuration provided by initial-config.json to model version 6.1
Keith Wall created QPID-7356:
Summary: Change default configuration provided by
initial-config.json to model version 6.1
Key: QPID-7356
URL: https://issues.apache.org/jira/browse/QPID-7356
Project: Qpid
Issue Type: Task
Components: Java Broker
Reporter: Keith Wall
Fix For: qpid-java-6.1
{{initial-config.json}} stores the default configuration used for a new Java
Broker. It is currently at model version 6.0. Change the configuration to 6.1.
Also change its systest counterpart {{config-systest.json}} too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7356) Change default configuration provided by initial-config.json to model version 6.1
[
https://issues.apache.org/jira/browse/QPID-7356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7356:
-
Description:
{{initial-config.json}} stores the default configuration used for a new Java
Broker instance. It is currently at model version 6.0. Change the
configuration to 6.1.
Also change its systest counterpart {{config-systest.json}} too.
was:
{{initial-config.json}} stores the default configuration used for a new Java
Broker. It is currently at model version 6.0. Change the configuration to 6.1.
Also change its systest counterpart {{config-systest.json}} too.
> Change default configuration provided by initial-config.json to model version
> 6.1
> -
>
> Key: QPID-7356
> URL: https://issues.apache.org/jira/browse/QPID-7356
> Project: Qpid
> Issue Type: Task
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> {{initial-config.json}} stores the default configuration used for a new Java
> Broker instance. It is currently at model version 6.0. Change the
> configuration to 6.1.
> Also change its systest counterpart {{config-systest.json}} too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1228) Windows schannel needs default peer_hostname to match OpenSSL
[ https://issues.apache.org/jira/browse/PROTON-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379011#comment-15379011 ] Justin Ross commented on PROTON-1228: - [~cliffjansen], is this supposed to remain open for some pending piece of work? > Windows schannel needs default peer_hostname to match OpenSSL > - > > Key: PROTON-1228 > URL: https://issues.apache.org/jira/browse/PROTON-1228 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.13.0, 0.14.0 > Environment: Windows >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.13.1 > > > The OpenSSL module sets a default peer_hostname from the bound connection. > schannel.c should do the same to behave the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[SECURITY] CVE-2016-4467: Apache Qpid Proton: Failure to verify that the server host name matches the certificate host name on Windows
CVE-ID: CVE-2016-4467 Severity: Medium Affected versions: 0.8 through 0.13.0 (inclusive) Fixed in Versions: 0.13.1 and later Short Description: The Proton C client and C-based client bindings may fail to verify that the server host name matches the domain name in the subject's Common Name (CN) or subjectAltName field in X.509 certificates when running on Windows operating systems. Description: Messaging applications using the Proton C library to provide SSL/TLS authentication on Windows can falsely authenticate a server whose name does not match the server name in the connection specifier. Proton C bindings are affected to a greater or lesser degree depending on how they use the underlying Proton C library. In Proton C, this can only happen if PN_SSL_VERIFY_PEER_NAME has been specified as the verification mode and pn_ssl_set_peer_hostname() has not been called at all or has been called with a NULL value for a particular pn_ssl_t object. In the Proton C++ binding, this will always happen unless the application has separately specified a virtual_host name for an SSL/TLS connection. In the Proton Python and Ruby bindings, this will only happen if the application has separately specified a NULL virtual_host name for an SSL/TLS connection after creating the connection but before the authentication step. This issue only occurs on Windows versions of Proton that use the default SChannel-based security layer. In any of the preceding cases, it is possible for a man-in-the-middle attacker to spoof an SSL/TLS server if they had a certificate that was valid for any of the application's Certificate Authorities. Resolution: Proton release 0.13.1 resolves this issue in the SChannel-based security layer by obtaining a default non-NULL peer hostname from the associated connection address when initialized and by always failing hostname verification if PN_SSL_VERIFY_PEER_NAME has been specified along with a NULL peer hostname. This resolution matches the associated behaviour of the OpenSSL-based security layer. References: PROTON-1228 PROTON-1233
