Thanks for adding this feature. I am sure it is going to be heavily used. BTW
- can you point me to where I can I download ActiveMQ 4.1?
--
View this message in context:
http://www.nabble.com/Nested-MapMessage-tf1788442.html#a5617829
Sent from the ActiveMQ - Dev forum at Nabble.com.
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
Unfortunately, ObjectMessage does not work across heterogenous environments
- I see lots of systems being built nowdays with C# clients and Java
servers.
--
View this message in context:
http://www.nabble.com/Nested-MapMessage-t1788442.html#a4903443
Sent from the ActiveMQ - Dev forum at
One could allow Map or MapMessage or both as the second argument. The real
issue is that nested MapMessage should be allowed. I have no quibble with a
JMS provider allowing a Map as the second argument - as long as MapMessage
entries were accepted.
--
View this message in context:
There are a lot of real-world applications that need the ability to send
structured data via JMS.
For example, take an application that wants to publish a portfolio of bonds
(or stocks - take your pick). The logical way to do it would be to have a
portfolio container message with zero or more
Yes.
MapMessage has the same power and flexibility as XML (the universal
self-describing data structure) as long as arbitrary nesting is allowed.
Take away nesting and MapMessage becomes a very simplistic structure that
cannot easily handle real-world application needs.
In recognition of this
The JMS MapMessage API already contains the method setObject(name, val). For
nested MapMessage, the second argument - val - would simply be a MapMessage.
No need to clutter the API with yet another method. By the way, this is just
what TIBCO EMS provides.
--
View this message in context:
