activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dejan Bosanac" <>
Subject Re: Message transforming on broker
Date Wed, 23 Jan 2008 21:07:19 GMT
> Patches applied Thanks!  Keep em coming :)

Here it comes :) ... ... It's one big
cumulative patch, if it easier for you I can break it into few
separate patches.

> That sounds ok to me.  Perhaps we should add a header to the legacy
> frame to that folks know that the transformation failed either on the
> send or subscriber side.

I've added "transformation-error" header that contains a message of
the exception threw. Now consumer can check for that header before it
assumes that transformation took place.

> The one fishy thing is that it sounds like it's being used like a
> content-type.  Perhaps we should make the "transformation" purely a
> transient header that only controls sender / subscriber behavior.


> I'd like to work on making the default jms-xml transformation support
> all the JMS message types, especially MapMessage.

Now the transformer supports Object, Map and Byte messages. I've
changed header semantics a bit, so instead of jms-xml we now use
jmx-object-xml. Current translator supports the following header


I've also renamed the class from XStreamFrameTranslator to
JmsFrameTranslator, since it kind of do translation of standard jsm
messages, the thing it uses XStream for that is not that important. I
didn't make OXM transformer, but if there is an interest it could be
easily created, just like appropriate message transformer

* Spring support

Now XStream could be configured in the application context (just as it
has been used in test cases). I made a simple XStreamFactoryBean for
this purpose.

I think this should be complete now. I have a few minor tweaking on
todo list, but they are not critical. If this is OK, I would first
concentrate on the documentation.
A few questions about the documentation: should this go into the
specification or is it a AMQ-specific feature? If it should be
documented in the protocol, should we freeze 1.0 as it is and make a
1.1 with this as extra (so that current clients could remain 1.0

Dejan Bosanac

View raw message