On Tue, Jan 29, 2013 at 1:44 PM, Fraser Adams <[email protected]> wrote: > Hi Rajith, > Yeah I realise in retrospect that it was discussed, I guess that my point is > that it was only really flagged the once on the User mailing list and it > passed my by largely as I was looking at other things. That's why I was > using it as an example to back up Gordon's comment about unifying > communication on the user and development list.
I do agree that this is a problem and have voiced my support for unifying our mailing lists. > From your comment below are you saying that this is exposed in a choice of > three forms. It appeared to me as an instanceof MapMessage - how would I get > it to behave as say a org.apache.qpid.jms.ListMessage? is there a config > option or can I just cast it? You can cast it to the said interface. List message interface has a method called asList() to retrieve a java.util.List or you can use methods like get(int index) If you use -Dqpid.use_legacy_stream_message=false, then the sender could work with the standard stream message interface and it will get sent on the wire as a List Message. On the receiver side, you could use the stream message methods as well. > I don't suppose that you happened to make org.apache.qpid.jms.ListMessage > implement java.util.List as well as javax.jms.Message?? :-) You say "it > provides methods like the ones in java.util.List " but does it actually > implement that interface? > > Re "for the client to provide out of the box support instead of receiving as > bytes messages and having to decode the payload themselves. ". I've got > sympathy with this for sure - I guess I was just bitten by the change and > also as I've stated my personal view is that the correct approach is to use > ObjectMessage. I'm not sure I'm winning that argument with yourself and > Gordon, but I will keep banging on about it :-) I'd be interested to know > what others think about this. As I said in my reply to Gordon a combination > of List/Map in ObjectMessage plus exposing AMQP Content-Type will a) > maximise consistency between JMS and qpid::messaging and b) keep within the > JMS spec. Both of these are IMHO a really good thing. > > Regards, > Frase. > > > > On 29/01/13 16:27, Rajith Attapattu wrote: >> >> Hey Fraser, >> >> The patch was extensively discussed here >> https://reviews.apache.org/r/6816/ >> We expose the List message using >> 1. Map Message >> 2. Stream Message >> 3. org.apache.qpid.jms.ListMessage >> >> I personally don't like the Map Message approach (see my comments on >> the above review request). >> I also think it's hideous. >> >> But you might like the ListMessage interface as it provides methods >> like the ones in java.util.List >> >> The point of adding list message support is for the client to provide >> out of the box support instead of receiving as bytes messages and >> having to decode the payload themselves. >> >> Regards, >> >> Rajith >> >> On Sat, Jan 26, 2013 at 10:43 AM, Fraser Adams >> <[email protected]> wrote: >>> >>> As a follow up to my posting below. >>> >>> QMF2 is indeed broken by Java changes in Qpid 0.20 and my hunch around >>> somebody messing with how Content-Type amqp/list is encoded and decoded >>> does >>> indeed look to be "the smoking gun". >>> >>> I added some debug code to my getObjects() and I was hitherto receiving a >>> BytesMessage, which did need some decoding to retrieve the List, but now >>> it >>> is receiving a MapMessage. >>> >>> I've only started looking, but doing: >>> >>> MapMessage m = (MapMessage)response; >>> for (Enumeration e = m.getMapNames() ; e.hasMoreElements() ;) >>> { >>> String key = (String)e.nextElement(); >>> System.out.println("key = " + key); >>> } >>> >>> indicates (for the "broker" object) "key = 0" >>> >>> Which is suggesting that Lists now seem to be encoded in MapMessages with >>> keys that are indices :'( . >>> >>> >>> >>> To be fair Rajith Attapattu did post on this subject at the end of >>> August: >>> >>> http://qpid.2158936.n2.nabble.com/JMS-ListMessage-support-tp7581434.html >>> >>> and perhaps I *should* have taken more notice, however it was a single >>> posting and pretty inconclusive, so I don't thing that it was >>> unreasonable >>> for me to park it in "things to look at once the QMF stuff is released" >>> given where I was trying to focus my spare time. >>> >>> >>> IMHO this is *exactly* the sort of thing that acts as a "/quod erat >>> demonstrandum/" to Gordon Sim's posting on "mailing lists and fragmented >>> communication", 'cause I'd have got a *whole lot more* animated about the >>> subject if I'd have thought that this stuff was going to actually make it >>> in >>> to a release (see below!!)..... >>> >>> Have I just missed where the release notes communicated this, or is this >>> a >>> change that hasn't been communicated to "users" (aside from Rajith's >>> posting)?? >>> >>> >>> >>> I have to say that IMHO whilst the BytesMessage stuff (and the associated >>> decoding) "wasn't exactly ideal" I think that the way MapMessage has been >>> used here using String keys as indices feels pretty hideous too :-( >>> >>> There was some talk too in Rajith's post around "Make the list message >>> accessible via the MapMessage and StreamMessage interfaces" I'm not sure >>> if >>> this has been done, but TBH I'm not sure that I like StreamMessage any >>> better!! >>> >>> >>> >>> At the risk of coming over a bit anally retentive.......Here's what I >>> should >>> have taken the time to respond to >>> http://qpid.2158936.n2.nabble.com/JMS-ListMessage-support-tp7581434.html >>> with: >>> >>> >>> I don't actually like MapMessage a whole lot more than any of the above. >>> I >>> think that even for exposing amqp/map its use is flawed for (at least) >>> two >>> reasons: >>> 1) MapMessage is frankly a hideous interface that should have been kicked >>> into touch years ago by Sun. The particular axe I've got to grind with it >>> is >>> that there's this thing called java.util.Map which has been around since >>> Java 1.2, so it's spectacularly unhelpful to have a different interface >>> for >>> Maps transported via JMS. Among other things It really bugs me having to >>> use >>> Enumerations and not being able to use foreach. >>> >>> It's even more irksome becase QMF often comprises Maps of Maps, so the >>> top >>> level Map ends up being a MapMessage and the rest end up being >>> java.util.Map. It's not at all elegant and frankly I ended up writing a >>> "getMap(final Message message)" method that populates a java.util.Map >>> with >>> the messageProperties and Map values so I'd get at least some >>> consistency. >>> >>> 2) Possibly the main reason using MapMessage is flawed though is because >>> the >>> JMS Spec says: >>> "A |MapMessage| object is used to send a set of name-value pairs. The >>> names >>> are |String| objects, and the values are *primitive data types in the >>> Java >>> programming language*", that's right "primitive data types". To be fair >>> it >>> then goes on to include byte[] in the list and it *does* include a >>> getObject() and setObject(), but the JavaDoc explicitly says "This method >>> works only for the objectified primitive object types (|Integer|, >>> |Double|, >>> |Long| ...), |String| objects, and byte arrays. ". >>> >>> >>> So the bottom line is then that encoding java.util.Map and java.util.List >>> into javax.jms.MapMessage (which are clearly necessary for QMF plus a >>> whole >>> load of other things) *explicitly* breaks the JMS specification (as well >>> as >>> having a really hideous interface). >>> >>> As for StreamMessage that says: >>> "A |StreamMessage| object is used to send a stream of primitive types in >>> the >>> Java programming language" and the writeObject() method JavaDoc says >>> "This >>> method works only for the objectified primitive object types (|Integer|, >>> |Double|, |Long| ...), |String| objects, and byte arrays. ". So again >>> explicitly primitive types. >>> >>> >>> I've said the following a couple of times on the Qpid Users mailing list, >>> but nobody has yet bitten, hopefully this issue might start the >>> discussion >>> again.... >>> >>> IMHO the *only* correct way to expose amqp/map or amqp/list in JMS in a >>> way >>> that doesn't break the JMS specification is to use >>> javax.jms.ObjectMessage. >>> >>> ObjectMessage says: >>> >>> " >>> An |ObjectMessage| object is used to send a message that contains a >>> serializable object in the Java programming language ("Java object"). It >>> inherits from the |Message| interface and adds a body containing a single >>> reference to an object. Only |Serializable| Java objects can be used. >>> >>> If a collection of Java objects must be sent, one of the |Collection| >>> classes provided since JDK 1.2 can be used. >>> >>> " >>> The last paragraph is particularly interesting and is suggesting to me >>> that >>> this is exactly what is being implicitly suggested by Sun/Oracle as the >>> preferred way of passing Collections of various sorts via JMS. >>> >>> >>> Now to be fair things were perhaps more awkward in older versions of Qpid >>> when the AMQP Content-Type wasn't getting exposed in JMS, but even >>> without >>> being able to use the Content-Type to avoid speculating casting and >>> instanceof it still seems preferable. The Content-Type however can add >>> value >>> and make the whole thing completely consistent and well specified. >>> >>> >>> >>> Sorry that this has gone on somewhat, and I apologise for not >>> contributing >>> these thoughts when Rajith originally mentioned this (in retrospect it >>> would >>> probably have saved me quite some work). >>> >>> I hope that I've managed to convince the community that: >>> a) javax.jms.ObjectMessage is the "one true" JMS specification compliant >>> way >>> of exposing amqp/map and amqp/list >>> b) that there's not a huge gulf between "developers" and "users" and some >>> of >>> the choices can have big impacts particularly where "messing with >>> interfaces" in a not massively well controlled manner is concerned. >>> >>> Food for thought??? >>> >>> I'll make a start getting the QMF2 stuff working with the Qpid 0.20 >>> changes. >>> Now that I know what I'm up against it's not especially difficult, but >>> Lists >>> are used in a few places so I'll probably spend a bit of time trying to >>> make >>> sure I've covered it all off and trying to ensure I've abstracted >>> sufficiently from the underlying JMS Message type so that it won't be too >>> hard to accommodate ObjectMessage if (when???) things move to that. >>> >>> >>> And Rajith, if any of the stuff above comes across as me having a go at >>> you >>> it's *really* not my intention. I hope it doesn't come across like that, >>> but >>> emails can come across in ways not intended so I want to make that clear >>> up >>> front! I really should have put all of this stuff in a response to your >>> post, I'm afraid I was just trying to keep focus on my GUI. A flawed >>> decision on my part as it turns out :-D >>> >>> I'll keep you posted. >>> Frase >>> >>> >>> On 26/01/13 11:32, Fraser Adams wrote: >>>> >>>> Gripes so far...... I'm afraid it looks like 0.20 has broken QMF on >>>> Java. >>>> >>>> I've built the main qpid-all.jar and pointed my CLASSPATH at it and >>>> unfortunately "fings is well broke, innit?" :-( >>>> >>>> It's lower level than the GUI stuff as none of the QMF2 stuff is working >>>> and my QpidConfig port reports "No broker QmfConsoleData returned". My >>>> initial suspicion is still that somebody has messed around with how AMQP >>>> list messages are deserialised in Java, but I'll need to dig around a >>>> bit >>>> :-( >>>> >>>> On a more minor (and I'd assume unrelated) note I see the following on >>>> every Java Client I've fired up so far: >>>> >>>> log4j:WARN No appenders could be found for logger >>>> (org.apache.qpid.jndi.PropertiesFileInitialContextFactory). >>>> log4j:WARN Please initialize the log4j system properly. >>>> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for >>>> more info. >>>> >>>> >>>> Odd that it's just that one class >>>> >>>> I haven't built the C++ broker/client yet and the Java glitch seems to >>>> concur with what Gordon saw last week (it looks like a change between >>>> 0.18 >>>> and 0.20 as when he used 0.18 jars and pointed at a 0.20 broker things >>>> worked fine) so Java looks like the place to go digging. >>>> >>>> I'll keep you posted. >>>> >>>> Regards, >>>> Frase. >>>> >>>> >>>> On 23/01/13 15:30, Justin Ross wrote: >>>>> >>>>> The Apache Qpid community is pleased to announce the immediate >>>>> availability of Apache Qpid 0.20. >>>>> >>>>> Apache Qpid (http://qpid.apache.org) is a cross-platform enterprise >>>>> messaging solution which implements the Advanced Message Queuing >>>>> Protocol (AMQP, http://www.amqp.org). It provides brokers written in >>>>> C++ and Java, along with clients for C++, Java JMS, .Net, Python, >>>>> Ruby, and Perl. >>>>> >>>>> Qpid 0.20 is available from our website: >>>>> >>>>> http://qpid.apache.org/download.html >>>>> >>>>> The 0.20 release includes many bug fixes and improvements. We >>>>> recommend that all users upgrade. A comprehensive list of changes in >>>>> the 0.20 release is available here: >>>>> >>>>> http://qpid.apache.org/release_notes_0.20.html >>>>> >>>>> Thanks to all the users and contributors who have helped to improve >>>>> Apache Qpid. >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
