I'll start by saying I also welcome the work fraser has done, and given it is one of the primary reasons he was given commit rights look forward to it making its way onto trunk.
On 25 March 2013 20:27, Fraser Adams <[email protected]> wrote: > On 25/03/13 19:47, Rob Godfrey wrote: > >> In the meantime have you got a list of all the areas where the Java >> Broker and C++ broker are incompatible? I'm sure Gordon and I wouldbe >> very interested in that and would do our utmost to try to narrow that >> gap. >> >> Thanks again, >> Rob >> >> Hi Rob, I'm afraid that I haven't got a full list as yet. The good news > is that an awful lot is pretty similar. I noted some gaps in the Session > objects in the Java broker - IIRC I think it was linking between session, > subscription and queue. It's a little detail but it's useful in my GUI I > can start with a connection and navigate through session and subscription > to queue and vice versa I can start with a queue and navigate to > connection. I suspect that I may be the only person who actually uses this > behaviour :-D but I've also used it in another place where I audit queues > and if someone tries to create or connect to a queue I don't have in a > whitelist I log the connection information. Clearly I can't do that with > the Java broker with this little piece of linkage missing. To be fair it's > only really 'cause the Java broker model is a work in progress and it's > marked as "TODO". > That is something that was specifically considered as an end piece of functionality, but just hasnt been implemented yet. Rob started by trying to ensure that the HTTP interface covereed the existing JMX functionality but the intention is definitely that it expands beyond that (and already has, just not in this area yet, again basically due to priorities and time constraints). > > The main differences that I think cause pain is in the Queue object. It > looks like there are a lot of differences between the Queue definitions for > the C++ and Java brokers. For starters no ring queue in the Java broker (I > use that all the time) but other differences relate to the fact that all > the little config options seem to be different. > > Yes, the queues are the are of most difference, mainly due to different points of implementation and probably specific requirements by particular users of each broker over time (for example, whilst a few might actually like it, most of the users I deal with in relation to the Java broker would have a heart attack at the thought of ring queues hehe..and since noone has ever really nagged us about it, its just been something that never hit the top of any lists). > I found a list here https://cwiki.apache.org/** > confluence/display/qpid/Qpid+**extensions+to+AMQP<https://cwiki.apache.org/confluence/display/qpid/Qpid+extensions+to+AMQP>I > don't know how complete it currently is but skimming through it it looks > consistent with what I've noted. As you can see the bulk of the differences > are in Queue.Declare. Clearly this also means that AddressStrings can't > really be used interoperably between the two brokers - at least with the > management interface it's possible to "shim" to some degree between QMF and > the Java broker internal model to try to expose some level of commonality > clearly that won't fix it when AddressStrings are being used. > > I was planning on having a go adding stuff to the Java broker > ConfiguredObjects when I'd got the other stuff committed, but the plugin > changes and the questions about where to put the Java QMF stuff are likely > to delay that a little. > > Frase > > If there is specific ideas you have, feel free to send out a mail and we can discuss how best to do things :) Robbie
