Re: Proton's road ahead

On Mon, 2016-10-31 at 18:26 +, Rob Godfrey wrote: > On 31 October 2016 at 17:28, Robbie Gemmell > > wrote: >  > > > I was going to bring up a similar question - do we believe we are > > actually > > > > > > getting benefit from trying to keep the API of Proton-J

Re: qpid monitoring tool in GO

On Fri, 2016-10-28 at 17:05 +0100, Gordon Sim wrote: > On 28/10/16 16:56, Andrew Stitcher wrote: > > > > If you go to godoc.org and search for AMQP there, you won't find > > the > > electron library anywhere near the top of the list. > > If you search for AMQP 1.0 you get nothing, so we should

Re: Proton's road ahead

On 31 October 2016 at 17:28, Robbie Gemmell wrote: > On 31 October 2016 at 16:37, Rob Godfrey wrote: > > On 31 October 2016 at 16:06, Robbie Gemmell > > wrote: > > > >> I don't think there is anything too surprising

Re: Proton's road ahead

On 31 October 2016 at 16:06, Robbie Gemmell wrote: > I don't think there is anything too surprising in what you said, given > previous discussion and how things have actually progressed over the > past couple of years. > > Messenger is covered upon in your comments, but

Re: SSL server

The link describes configuring qpidd, which is what the file names you referenced are configuration from, for use with the Cyrus SASL library (proton-c can also use cyrus, but has its own configuration for that). I think what you are asking is how to configure proton-j similarly. Proton-j does

Re: SSL server

The proton transport isn't used for SSL in the JMS client, but the thing I'm thinking of is more likely to happen when SSL is being used. In this case it would most likely be a bug in the client and the server, but a server could do it deliberately, and it would be something the client should cope

Re: Proton's road ahead

I don't think there is anything too surprising in what you said, given previous discussion and how things have actually progressed over the past couple of years. Messenger is covered upon in your comments, but slightly more in relation to the proton-c (+bindings) side. I think its worth going

Proton's road ahead

Hi, everyone. I’m writing this to give you all a clearer picture of our intentions for Apache Qpid Proton and to invite your feedback. There are several moving parts, so I’ll take them in turn. Messenger and Proton APIs. The Messenger API has been a source of trouble for us for a long time.

[CANCELED][VOTE] Release Qpid for Java 6.1.0

The voting [1] is canceled due to a number of issues found in new features introduced in 6.1.0 RC1 build of Qpid for Java. We are going to spin RC2 build where found issues will be fixed. Kind Regards, Alex [1] http://qpid.2158936.n2.nabble.com/VOTE-Release-Qpid-Java-6-1-0-td7652361.html

[RESULT] [VOTE] Release Qpid for Java 6.0.5

There were 4 binding +1 votes, and no other votes received. The vote has passed. Voting thread: http://qpid.2158936.n2.nabble.com/Fwd-VOTE-Release-Qpid-Java-6-0-5-td7652349.html I will publish release artifacts into release repositories and I will update web site in 24h after repo mirrors

Re: [VOTE] Release Qpid Java 6.0.5

+1 I tested publishing messages with AMQP 1.0 JMS client, receiving them with AMQP 0.10 JMS client and vice versa. I performed smoke test of web management console by creating and binding a queue. On 28 October 2016 at 16:44, Robbie Gemmell wrote: > On 24 October

Re: SSL server

Robbie, this links describe PLAIN mechanism for Proton-C, but i`m using Proton-J. It will be nice to have PLAIN or other mechanisms in Proton-J for authentication on the server side. link1

Re: SSL server

Robbie, i think in that case transport had been used for ssl handshake, and after this client trying to initialize transport frame size again. Also i test my ssl server with other client and it works. In conclusion it