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.
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?
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]
