> On Aug. 29, 2012, 7:01 a.m., Gordon Sim wrote:
> > I quite liked the approach taken in Siddhesh's patch (as attached to the
> > JIRAmany months ago now), where a list message can be processed by the
> > receiver in a variety of ways: (i) the elements of the list are accessible
> > through a MapMessage interface using their indices as the keys, (ii) the
> > message can be treated as a StreamMessage, (iii) a non-standard ListMessage
> > interface is introduced for those who prefer something a little more
> > explicit and don't mind the non-standard interface.
> >
> > For the receiver side these approaches seem a little more natural to me. I
> > would argue the first two are actually closer to the spirit of working
> > within the standard interfaces. I don't think the third option is
> > necessarily any less standard than a special key & property either.
> >
> > The view from the sender side is perhaps a little different however. I
> > *think* Siddhesh's patch requires list messages to be sent as the
> > non-standard ListMessage implementation for them to be actually encoded as
> > an AMQP list. It would be nice to be able to use the more standard
> > interfaces as the receiver can, even if just for the symmetry. The trick
> > there would be determining how to encode the message in the AMQP type
> > system. A message property seems like the 'best' option there. Perhaps it
> > could be more directly tied to content-type though. Do we expose that at
> > all through a custom proprty key in JMS?
> >
> > It should certainly also be possible to add a List object as the value to a
> > particular key in a MapMessage (non-standard JMS behaviour of course, so
> > perhaps configurable) which your patch does and his may not(?).
> >
> >
I did look at the patch very closely and debated several options before
settling down with the one I proposed. Here's why,
I was looking at using either a StreamMessage or as a special case of Map
Message on both ends (for symmetry).
I chose MapMessage as you can easily do getObject() to retrieve a
java.util.List and from then onwards the application gets to work with the List
interface which is the most natural one for java developers.
With StreamMessage it's not very intuitive or natural.
Here's why I disliked the existing patch
========================================
(1) I really dislike introducing a Qpid specific interface and I don't believe
it's the same as using a special key & message property. The latter certainly
gives more flexibility to the application and us as the vendor.
(2) I think it's more natural to allow the application deal with a
java.util.List than to allow access to elements using
getObject("index-as-a-string").
With the latter we will then need to handle array-index-out-bounds, typos
in the indicies, non numeric keys etc.. where's we don't need to worry with a
List.
(3) Further to the above point, Java has syntatic sugar (for each ..etc) for
List processing which will not be possible with the above approach.
(3) Multiple interfaces to access the same message content is error prone and
confusing IMO.
- rajith
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6816/#review10835
-----------------------------------------------------------
On Aug. 29, 2012, 2:34 a.m., rajith attapattu wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6816/
> -----------------------------------------------------------
>
> (Updated Aug. 29, 2012, 2:34 a.m.)
>
>
> Review request for qpid, Gordon Sim, Robbie Gemmell, Weston Price, and Keith
> Wall.
>
>
> Description
> -------
>
> We have a need to support amqp encoded list messages that are understood
> across all language clients. In JMS this is a bit difficult as there is no
> direct list message interface like the map message.
> I wanted to introduce a way of getting list message support while using only
> JMS interfaces.
>
> The list message support is implemented as a special case of Map message,
> where the only entry is a list (it can be nested lists as well).
> The application notifies the client of their intention via a message header.
> MapMessage m = _session.createMapMessage();
> m.setBooleanProperty("encode-as-list", true);
> m.setObject("amqp/list", myList);
> _producer.send(m);
>
> The resulting message body will be encoded as an AMQP 0-10 list. A C++ or
> python client can then directly read it as a list message.
>
> On the receiving side, it will be presented as a MapMessage with a single
> entry retrieved using "amqp/list".
> List list = (List)m.getObject("amqp/list");
>
> Please feel free to provide feedback, including alternative ways of
> implementing this.
> All feedback are most welcomed!
>
>
> This addresses bug QPID-3906.
> https://issues.apache.org/jira/browse/QPID-3906
>
>
> Diffs
> -----
>
>
> http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/message/AMQPEncodedListMessage.java
> PRE-CREATION
>
> http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/message/AMQPEncodedListMessageFactory.java
> PRE-CREATION
>
> http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/message/AMQPEncodedMapMessage.java
> 1378417
>
> http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/message/AbstractJMSMessage.java
> 1378417
>
> http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/message/MessageFactoryRegistry.java
> 1378417
>
> http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/client/message/AMQPEncodedListMessageTest.java
> PRE-CREATION
>
> http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/client/message/AMQPEncodedMapMessageTest.java
> 1378417
>
> Diff: https://reviews.apache.org/r/6816/diff/
>
>
> Testing
> -------
>
> AMQPEncodedListMessageTest is added to cover several cases.
>
>
> Thanks,
>
> rajith attapattu
>
>
