I've implemented support for nested MapMessage; so that they can contain entires containing arbitrarily deep Map and List objects. This patch also allows nested Map and List objects on JMS Message properties as well.
More details of this new feature here... http://activemq.org/site/structured-message-properties-and-mapmessages.html On 6/16/06, James Strachan <[EMAIL PROTECTED]> wrote:
On 6/16/06, jhakim <[EMAIL PROTECTED]> wrote: > > Clearly both setObject(name, map) and setObject(name, mapMsg) work. As you > correctly point out, using a hierarchical naming scheme would allow the > client to specify nesting and works with any MOM. > > However, I would argue that forcing clients to write code to create/parse a > hierarchical naming scheme defeats the key goal of ease of use. > > For instance, suppose one wants to create a framework for marshaling > arbitrary beans to JMS messages. A logical implmentation would be to use > reflection to discover bean properties and create a corresponding > MapMessage. Now, suppose that a bean contains other beans as properties. One > elegant approach would to marshal each bean property to a nested > MapMessage. This exact strategy is used by many systems on Wall Street and > by open-source projects (messageforge.sourceforge.net). > > BTW - the underlying JMS provider can, beneath the covers, use hierarchical > naming schemes and strip off properties from nested messages. As far as the > client is concerned, this should just be an implementation detail and not > the required way for clients to use the MOM. Agreed. Obviously if you have a nested array of beans you can obviously use ObjectMessage too - but I totally understand the motivation for having a typesafe hierarchial MapMessage that other languages can parse too. I've created an issue to track this feature request http://issues.apache.org/activemq/browse/AMQ-757 -- James ------- http://radio.weblogs.com/0112098/
-- James ------- http://radio.weblogs.com/0112098/
