Thanks for the response Gordon. I'll look at the qpid specific
ListMessage for the next release of my QMF stuff. I only noticed the
MapMessage encoding at the weekend and I wanted to get something up and
working for Qpid 0.20. I wasn't too happy with the MapMessage especially
as there's no way to get the size() so getting from that to the
java.util.List that things like my getObjects() returns required me to
create an ArrayList with an arbitrary size.
Re the other points in this thread. I think that we are converging :-)
I'm pleased that you agree with the comments on exposing Content-Type, I
really do think that this is the way to go to allow clients to be clear
on things.
When I said "ObjectMessage is the only way to expose amqp/map and
amqp/list" I did caveat that with "and properly conform to the spec. "
:-) I'm not violently opposed to "Being able to treat it as some other
message type may also be reasonable. " and I know from our conversations
wrt. Proton that you've got some views with respect to providing choice.
That's kind of fair, though my *personal* view is that it's ultimately a
good idea to provide consistency and encourage common design patterns.
<obtuse>To be fair my comment about the spec. wasn't *entirely* correct,
BytesMessage plus a private encoding also conformed to the spec, though
I'd definitely agree that this wasn't the friendliest thing in the world
to use - I'd never have worked that out without your little code snippet
:-)</obtuse>
Re "If I send a simple map, receiving it from JMS as a MapMessage seems
reasonable" - being very glib IMHO there's nothing terribly reasonable
about MapMessage :-) I *really* don't know why I'm so prejudiced against
MapMessage, but for some reason I've got a violent dislike for it :-/ it
must have had bad karma from a previous life. I *think* that it stems
from it feeling a bit old fashioned and rather inconsistent. When Sun
introduced Collections there came a good range of consistent interfaces,
which meant that one rarely needs to use things like HashTable etc., but
MapMessage is a bit stuck in those dark ages, not being able to get a
size and having to use Enumerations to iterate kind of offend me :-) And
I can't stick anything in if aside from a primitive a String or a byte[]
(well if I read the spec :-p)
So thanks again, I think that we've got a good set of common ground even
if we don't agree 100% on everything (I'm bound to bang on about the
spec. at some point again :-))
Cheers,
Frase
On 29/01/13 19:05, Gordon Sim wrote:
On 01/29/2013 06:44 PM, Fraser Adams wrote:
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 should be able to cast it to MapMessage, StreamMessage or the qpid
specific ListMessage, whatever suits best. Being additionally able to
cast to a BytesMessage or an ObjectMessage would I think be great
barring any issues with that I might be missing. My view in short is
that if the data can be exposed through a particular interface than we
should do so if requested.
---------------------------------------------------------------------
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]
