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.
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.
--
Regards,
Hiram
Blog: http://hiramchirino.com
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
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
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
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
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:
http
(nested) bond messages. The
alternative, breaking a portfolio into a series of bond messages, is VERY
cumbersome and requires that the consumer reconstruct the portfolio.
This is but one instance of a real-world need to publish arbitrary message
structures. Nested MapMessage addresses this need
structures. Nested MapMessage addresses this need directly and elegantly.
Yes.. but nested Maps also addresses the same issue it seem to me.
What does nesting MapMessages buy you that nested Maps do not?
--
View this message in context:
http://www.nabble.com/Nested-MapMessage-t1788442.html#a4877171
So is this just to be compatible with EMS or is there another handy
reason that being able to embedd a map message is needed?
On 6/15/06, jhakim [EMAIL PROTECTED] wrote:
One could allow Map or MapMessage or both as the second argument. The real
issue is that nested MapMessage should be allowed
://www.nabble.com/Nested-MapMessage-t1788442.html#a4873966
Sent from the ActiveMQ - Dev forum at Nabble.com.
poor design strategy
because it binds clients too closely with the vendor API.
--
View this message in context:
http://www.nabble.com/Nested-MapMessage-t1788442.html#a4873966
Sent from the ActiveMQ - Dev forum at Nabble.com.
--
Regards,
Hiram
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:
http
). 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:
http://www.nabble.com/Nested-MapMessage-t1788442.html#a4875002
Sent from the ActiveMQ
14 matches
Mail list logo
