Rajith Attapattu wrote:
I'm pretty worried that you're comment "If you do a getStringProperty on a
byte[] it will throw an exception."
What do you think the correct behaviour should be in this case ?
Well that's an interesting philosophical question :-)
So I think that the "correct" behaviour is to live within the JMS spec.
so throwing an Exception is probably the "correct" thing to do, but
there's a question of what's most intuitive that is perhaps more subtle.
So for example if I'm getting a string property I'm probably expecting a
string and I'm probably expecting whoever populated it to have put a
string (in the general sense) into it. So intuitively if not
scientifically it seems reasonable to return the most likely string
representation. So it's not total blasphemy to infer that a byte[]
within the context of getString() is really probably a string of some sort.
Your argument wrt. List/Map/UUID is reasonable but as you say
getObjectProperty() could certainly cater for these. And a
getStringProperty() on a UUID could in fact quite reasonably return
UUID.toString() that's actually I suspect what most people would be
expecting from that.
Perhaps it's not perfect to deviate from the JMS spec, but it's
perfectly possible to document non-compliances. In any case some of the
other default behaviours play hard and loose with the JMS spec, for
example unless I'm mistaken the spec says that the client runtime should
only return from the "send()" method once the message has been handed
over to the broker. With Qpid the default behaviour is to behave
asynchronously and it required a property to be set to force fully JMS
compliant behaviour. Incidentally I think the current behaviour there is
the right thing to do as synchronous behaviour hoses performance, but
nonetheless it's a trap for the unwary who might expect JMS compliance
and I'd argue that's perhaps a more significant "off spec" than treating
something that is likely intuitively a "string" as a String.
Like I say it's an interesting philosophical question - and you did ask
what I thought :-D
Maybe you misunderstood. Currently we throw an exception only if you
try to retrieve a byte[] as a String property.
Frankly it doesn't make sense, so an exception is reasonable.
However if you try to retrieve as an objectProperty it should work :)
Thank you,thank you thank you. Whew, I saw your original post last thing
last night and I was thinking about how I might work around it for ages
:-) I was really tearing my hair out when I first started trying my
Console out with a few different Agents, which is what led me to my
magic String un-mangler :-) Just wait until you see what I had to do to
work around the fact that List types aren't supported :-)
Incidentally........ this is kind of a question for you and Gordon really.
As it stands AMQP Map types are encoded/decoded as JMS Map Messages now
whilst that's fairly intuitive (sort of) it's actually just a bit of a
pain. JMS Map Messages are a bit "old skool" and in the 21st century I'm
tending to think that it would be awfully nice to be getting Maps as
java.util.Map.
With Lists Gordon has previously mooted using StreamMessages, but I
think that that's not ideal as I'm pretty sure that the JMS Spec
specifies the same type limitations as Properties.
My own thinking is somewhat converging to the view that using Java
Object Messages with the available types being mappings to AMQP types is
ultimately the most useful approach - though how to change behaviour
without breaking existing clients would be an interesting client
(compatibility property perhaps?). Using Object Messages in this way
might also make it a lot easier to resolve the whole Content-Type
discussion - though personally I'd like to be able to get the
Content-Type to avoid "instanceof" the Object. Yes I do use instanceof
in plenty of places BTW, but it makes me feel just a little dirty :-)
And don't start me off on down-casting :-D
Cheers - thanks again I'll maybe sleep tonight :-D
Frase
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
