Qpid JMS 0.30.0 or Qpid Proton-J 0.26.0 to point-to-point message exchange?

Hi everybody, We are working with Qpid to set up interoperability between 2 systems, one in Java, the other in C ++. On the C ++ side, we use Qpid Proton 0.17.0 (not the last update due to system constraints) to use the AMQP 1.0 standard. In Java, we started on Qpid JMS 0.30.0 for the

Re: Proton C source reorg and removal of deprecated or obsolete code

On Mon, Mar 12, 2018 at 12:14 PM, Justin Ross wrote: > > src/messenger still there - oversight, or do we need to hold onto this? > > > > It's still used by one of the test tools. > > We can replace msgr-send.c and msgr-recv.c by copying from examples/c/[send.c, send-ssl.c,

Re: Qpid JMS 0.30.0 or Qpid Proton-J 0.26.0 to point-to-point message exchange?

On 14/03/18 08:40, Cyril Micoud wrote: Hi everybody, We are working with Qpid to set up interoperability between 2 systems, one in Java, the other in C ++. On the C ++ side, we use Qpid Proton 0.17.0 (not the last update due to system constraints) to use the AMQP 1.0 standard. In Java, we

RE: Qpid JMS 0.30.0 or Qpid Proton-J 0.26.0 to point-to-point message exchange?

Hi Gordon, Thanks for your answer... We are agree with your first point and we look to try it as soon as possible. But we have also a 3rd system in Java and we need a direct access Java=>Java without any broker. I think the solution is your second point? In that case, how each system knew the

RE: Qpid JMS 0.30.0 or Qpid Proton-J 0.26.0 to point-to-point message exchange?

We use Qpid Broker-J 7.0.x... We have build a REST service based on Retrofit but it is very coupling with POJO structure (we use Custom POJO instead of Map return by REST api due to the simplicity to understand which object we manipulate). After see management via JMS message, I

Build failure in Qpid C++ legacystore tests

I'm seeing this when I enable legacystore. https://gist.github.com/ssorj/f9320463cb0c5f3318b0226577b5e305 [ 87%] Building CXX object src/tests/legacystore/CMakeFiles/jtt.dir/jrnl/jtt/test_case_result.cpp.oIn file included from /usr/include/boost/test/test_tools.hpp:45:0, from

Re: Qpid JMS 0.30.0 or Qpid Proton-J 0.26.0 to point-to-point message exchange?

As Gordon noted, the JMS client can't act as a server for incoming connections. Its only a client and must connect out, but the other side can be a broker/router/toaster/other. The 'reactor' impl which proton-j includes can accept, and there is a very basic/incomplete/naive 'recv' example which

Re: Qpid JMS 0.30.0 or Qpid Proton-J 0.26.0 to point-to-point message exchange?

On 14/03/18 12:19, Cyril Micoud wrote: how each system knew the dispatch router? They just need a host and port; that would be the same even if one was directly connecting to the other. - To unsubscribe, e-mail:

Re: Qpid JMS 0.30.0 or Qpid Proton-J 0.26.0 to point-to-point message exchange?

If you are 'reloading' an InitialContext to add new JNDI config, then depending on how you do that exactly I'd guess your application is coupled to either the syntax of the properties it uses or maybe just the implementation class. In either case, you could as well use session.createQueue() etc to

RE: Qpid JMS 0.30.0 or Qpid Proton-J 0.26.0 to point-to-point message exchange?

Thanks Gordon and Robbie for your answers. I have found the vertx-proton just few second before your response... it is very simple and I think we are going to use it to provide a light and simple server on our "client" java side. About JMS, I have seen a link (but where?) to manage

Re: Qpid JMS 0.30.0 or Qpid Proton-J 0.26.0 to point-to-point message exchange?

On 14 March 2018 at 17:13, Cyril Micoud wrote: > Thanks Gordon and Robbie for your answers. > > I have found the vertx-proton just few second before your response... it > is very simple and I think we are going to use it to provide a light and > simple server on our