JMS List support - oh dear! again.....

[Fraser Adams <fr...@blueyonder.co.uk>]

Hi Guys,
I was planning on having a look at the org.apache.qpid.jms.ListMessage 
stuff and move away from the cast to MapMessage, but a somewhat irksome 
thought struck me before I got started.

As the moment my QMF2 code can compile against more or less any version 
of the Qpid Java client runtime. I needed to include a specific target 
to build a patched AMQPMessageDelegate_0_10.java for versions below 0.10 
but everything else should currently just compile.


I'm guessing that org.apache.qpid.jms.ListMessage was added in 0.20, so 
if I actually use it compilation will break for everything else :-(

I'm not wildly keen on the MapMessage approach as you know, both for 
"philosophical reasons :-)" and because I can't get the size() so I need 
to "make up" a size for the ArrayList that I copy the elements from the 
MapMessage into. The asList() method on ListMessage looked to be the 
nicest option from the recent threads.


So I'm thinking that I'm going to either:
a) Have to stick with MapMessage 'cause I know that compiles across the 
board, but it offends me rather.
b) have a specific target for 0.20 onwards, which I don't especially 
like either.
c) Use reflection to find the asList(), which should be do-able and has 
a certain entertainment value, but I suspect will probably be less 
efficient than just living with the MapMessage inefficiencies - I can't 
say for sure, any thoughts on that?


Does anybody have any better suggestions than those that'll allow me to 
use lists across different Qpid releases without needing different builds?


Did I mention I preferred ObjectMessage :-) so this'll be another reason 
why I do :-D

Cheers,
Frase


On 29/01/13 20:18, Rajith Attapattu wrote:
> 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.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: JMS List support - oh dear! again.....

[Fraser Adams <fr...@blueyonder.co.uk>]

On 12/02/13 14:49, Rajith Attapattu wrote:
> Fraser,
>
> It seems that map message would probably be your choice.
:-(

Sound of (guitarists) fingernails scraping down a blackboard.......... 
to be fair MapMessage certainly wouldn't be my choice :-) but given the 
options.......
> I agree it's quite hideous.
There's a Scottish expression "nae very bonny" that sums it up nicely.....
>
> Another option I floated (and the majority didn't like it) was to have
> the list as a single entry in the map instead of having to do
> map.getObject("1").
It's all varying degrees of hideousness. So if I *have* to suffer the 
indignity of a MapMessage breaking the spec I'm tempted to suggest that 
map.getObject("amqp/list"); is no worse than any other option and 
somewhat does what it says on the tin. I guess that the problem now is 
we've now got a MapMessage with indices mapped to keys deployed in a 
Qpid release, so any changes will now break things for anyone using it.
>
> So you can do something like List list = (List)map.getObject("list")
> and then work with the list.
> A good compromise would be to have both approaches in the MapMessage
> interface for the List message.
So how would having both approaches work? Wouldn't you end up storing 
the data twice, once as the List and again as the items in the list 
keyed by indices? I'm sure that there's some storage cleverness that 
could be done but possibly a lot of effort. The lack of size() in 
MapMessage complicates things, so getting the list is nice enough but if 
anyone wants to mess around using the indices approach there's no way of 
knowing what the last value is - so then you'd have to Enumerate 
explicitly discarding the extra item with the "amqp/list" key.


Seriously, I know it's a soap box of mine but *please* think about the 
current MapMessage andObjectMessage and better ContentType exposure. 
I've tried to think through various permutations, but TBH nothing has 
yet convinced me that it's not the most "consistent" approach given that 
it can be done using existing JMS and Java Collection interfaces and as 
an idiom it's pretty consistent with qpid::messaging using content-type 
and Variant::Map/Variant::List.

I've stuck with Enumerating the current MapMessage for now 'cause at 
least it works.

Cheers,
Frase


>
> Rajith
>
> On Fri, Feb 8, 2013 at 4:31 AM, Fraser Adams
> <fr...@blueyonder.co.uk> wrote:
>> Hi Guys,
>> I was planning on having a look at the org.apache.qpid.jms.ListMessage stuff
>> and move away from the cast to MapMessage, but a somewhat irksome thought
>> struck me before I got started.
>>
>> As the moment my QMF2 code can compile against more or less any version of
>> the Qpid Java client runtime. I needed to include a specific target to build
>> a patched AMQPMessageDelegate_0_10.java for versions below 0.10 but
>> everything else should currently just compile.
>>
>>
>> I'm guessing that org.apache.qpid.jms.ListMessage was added in 0.20, so if I
>> actually use it compilation will break for everything else :-(
>>
>> I'm not wildly keen on the MapMessage approach as you know, both for
>> "philosophical reasons :-)" and because I can't get the size() so I need to
>> "make up" a size for the ArrayList that I copy the elements from the
>> MapMessage into. The asList() method on ListMessage looked to be the nicest
>> option from the recent threads.
>>
>>
>> So I'm thinking that I'm going to either:
>> a) Have to stick with MapMessage 'cause I know that compiles across the
>> board, but it offends me rather.
>> b) have a specific target for 0.20 onwards, which I don't especially like
>> either.
>> c) Use reflection to find the asList(), which should be do-able and has a
>> certain entertainment value, but I suspect will probably be less efficient
>> than just living with the MapMessage inefficiencies - I can't say for sure,
>> any thoughts on that?
>>
>>
>> Does anybody have any better suggestions than those that'll allow me to use
>> lists across different Qpid releases without needing different builds?
>>
>>
>> Did I mention I preferred ObjectMessage :-) so this'll be another reason why
>> I do :-D
>>
>> Cheers,
>> Frase
>>
>>
>> On 29/01/13 20:18, Rajith Attapattu wrote:
>>> 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.
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: JMS List support - oh dear! again.....

[Rajith Attapattu <ra...@gmail.com>]

Fraser,

It seems that map message would probably be your choice.
I agree it's quite hideous.

Another option I floated (and the majority didn't like it) was to have
the list as a single entry in the map instead of having to do
map.getObject("1").

So you can do something like List list = (List)map.getObject("list")
and then work with the list.
A good compromise would be to have both approaches in the MapMessage
interface for the List message.

Rajith

On Fri, Feb 8, 2013 at 4:31 AM, Fraser Adams
<fr...@blueyonder.co.uk> wrote:
> Hi Guys,
> I was planning on having a look at the org.apache.qpid.jms.ListMessage stuff
> and move away from the cast to MapMessage, but a somewhat irksome thought
> struck me before I got started.
>
> As the moment my QMF2 code can compile against more or less any version of
> the Qpid Java client runtime. I needed to include a specific target to build
> a patched AMQPMessageDelegate_0_10.java for versions below 0.10 but
> everything else should currently just compile.
>
>
> I'm guessing that org.apache.qpid.jms.ListMessage was added in 0.20, so if I
> actually use it compilation will break for everything else :-(
>
> I'm not wildly keen on the MapMessage approach as you know, both for
> "philosophical reasons :-)" and because I can't get the size() so I need to
> "make up" a size for the ArrayList that I copy the elements from the
> MapMessage into. The asList() method on ListMessage looked to be the nicest
> option from the recent threads.
>
>
> So I'm thinking that I'm going to either:
> a) Have to stick with MapMessage 'cause I know that compiles across the
> board, but it offends me rather.
> b) have a specific target for 0.20 onwards, which I don't especially like
> either.
> c) Use reflection to find the asList(), which should be do-able and has a
> certain entertainment value, but I suspect will probably be less efficient
> than just living with the MapMessage inefficiencies - I can't say for sure,
> any thoughts on that?
>
>
> Does anybody have any better suggestions than those that'll allow me to use
> lists across different Qpid releases without needing different builds?
>
>
> Did I mention I preferred ObjectMessage :-) so this'll be another reason why
> I do :-D
>
> Cheers,
> Frase
>
>
> On 29/01/13 20:18, Rajith Attapattu wrote:
>>
>> 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.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org