As steve mentions the language the broker is written in matters not, they speak AMQP and clients can do the same in whatever language they like which is one reason client language isn't overly mentioned in docs.
The examples that ship with both the AMQP 1.0 and AMQP 0-x JMS clients work against the C++ broker (and the Java broker, and other components that speak the appropriate AMQP version(s)). If using the AMQP 1.0 JMS client, you'll either need to pre-create the queue (named queue) that the examples use, or start the broker with config such that it will auto create it when a link (e.g a consumer) attaches. If compiling form source you also need to ensure proton-c is available first so the brokers AMQP 1.0 module actually gets compiled. If for example I am running the JMS examples against qpidd direct from a source build without installing it, I might start it without auth, explicitly load the AMQP 1.0 module, and ask it to auto-create queues with names beginning "queue" by running something like this in the build/src dir after compiling: ./qpidd --auth=no --load-module=amqp.so --queue-patterns queue.* I believe both brokers support message conversion, allowing clients with differing AMQP versions to communicate with each other to a fair degree. Robbie On 16 February 2016 at 21:46, Flores, Paul A. <paul.a.flo...@saic.com> wrote: > Steve, > > Exactly what I needed! Thank you! > > If we ever meet the first round is on me! > > Paul > > ________________________________________ > From: Steve Huston [shus...@riverace.com] > Sent: Tuesday, February 16, 2016 3:34 PM > To: users@qpid.apache.org > Subject: RE: QPID C++ broker and Java - One broker to "rule them all" > > Hi Paul, > >> -----Original Message----- >> From: Flores, Paul A. [mailto:paul.a.flo...@saic.com] >> Sent: Tuesday, February 16, 2016 4:26 PM >> To: users@qpid.apache.org >> Subject: RE: QPID C++ broker and Java - One broker to "rule them all" >> >> Steve, >> >> The compatibility table is what drew me to posting my original question. > > Ah, ok... did not realize that. > >> We are using the QPID Messaging API which notable does not list Java >> language support. > > Right. > >> Brokers appear to be language dependent implementations. > > Ah, I see the confusion.... the brokers have an overlapping but not > equivalent set of features but it doesn't matter what programming language > you use to access either one - it just matters which AMQP version(s) you want > to use. > >> In passing the >> C++ Broker documentation mentions in a one liner that it will work with JMS >> but no further details are provided. > > Ok - it will. There's nothing C++-ish about the C++ broker's interface to > clients. It works fine with JMS clients. In particular, if you want to avoid > AMQP 1.0 you should stick with the older JMS API - it can talk AMQP 0-10 to > the C++ broker. > >> We have looked at Proton but are not convinced it will fit into an existing >> framework without some really extensive changes to a CORBA like >> framework, hence the hesitation. > > Ok. > >> Which brings me to this question. Is there an example of QPID JMS utilizing >> the C++ Broker (qpidd)? > > I'm using it in a project now for a customer... (Camel -> JMS -> C++ broker) > > The examples hanging off http://qpid.apache.org/components/jms/amqp-0-x.html > should be a good start for you. > > -Steve > >> ________________________________________ >> From: Steve Huston [shus...@riverace.com] >> Sent: Tuesday, February 16, 2016 3:07 PM >> To: users@qpid.apache.org >> Subject: RE: QPID C++ broker and Java - One broker to "rule them all" >> >> There's a compatibility matrix on the page: >> http://qpid.apache.org/components/index.html >> If that doesn't contain all the info you need to help decide, try asking >> again - I >> may not understand the problem. >> >> -Steve >> >> > -----Original Message----- >> > From: Flores, Paul A. [mailto:paul.a.flo...@saic.com] >> > Sent: Tuesday, February 16, 2016 1:29 PM >> > To: users@qpid.apache.org >> > Subject: RE: QPID C++ broker and Java - One broker to "rule them all" >> > >> > Per Steve's advice: >> > >> > Environment: >> > Centos 5.11 (moving soon to 7) >> > C++: gcc 4.1.2 >> > Java: 1.7.0_95 >> > >> > QPID Messaging API: qpid-cpp-0.34 >> > C++ Broker >> > ________________________________________ >> > From: Steve Huston [shus...@riverace.com] >> > Sent: Tuesday, February 16, 2016 12:13 PM >> > To: users@qpid.apache.org >> > Subject: RE: QPID C++ broker and Java - One broker to "rule them all" >> > >> > As long as the front end, back end, and broker can speak the same AMQP >> > version, they should all play nice regardless of the programming language. >> > >> > If you can be a little more specific about the client code versions, >> > it's highly likely that someone can help point you to at least one broker >> > to >> do the job. >> > >> > -Steve >> > >> > > -----Original Message----- >> > > From: Flores, Paul A. [mailto:paul.a.flo...@saic.com] >> > > Sent: Tuesday, February 16, 2016 1:06 PM >> > > To: users@qpid.apache.org >> > > Subject: QPID C++ broker and Java - One broker to "rule them all" >> > > >> > > Situation: >> > > >> > > >> > > >> > > I am looking at a mixed language implementation. >> > > >> > > >> > > >> > > Server side (backend) is in C++ while user facing side (frontend) is >> > > Java. >> > > >> > > >> > > >> > > A fair amount of JNI "in play". >> > > >> > > >> > > >> > > Specific option of using JMS would be painful because there is a >> > > substantial amount of backend communications between servers. >> > > >> > > >> > > >> > > Questions are straightforward. >> > > >> > > >> > > >> > > How do I get both sides (backend and frontend) to use the same Broker? >> > > >> > > >> > > >> > > Is JNI the only option? >> > > >> > > >> > > >> > > Insights and comments are welcomed and appreciated. >> > > >> > > >> > > >> > > Paul >> > > >> > > >> > > >> > > p.s. I apologize for the "Lord of the Rings" reference in subject line. >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For >> > additional commands, e-mail: users-h...@qpid.apache.org >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For >> > additional commands, e-mail: users-h...@qpid.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional >> commands, e-mail: users-h...@qpid.apache.org >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional >> commands, e-mail: users-h...@qpid.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
