qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: JMS client skips string message properties
Date Wed, 21 Sep 2011 16:13:00 GMT
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:users-subscribe@qpid.apache.org


Mime
View raw message