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 Sun, 09 Mar 2008 15:45:42 GMT

I've documented a stomp message transformation feature (the part that is
currently committed)

We'll implement the functionality in PHP client soon, so it would be good if
someone could look at the other patch ( that includes map
messages, xstream customization, transformation errors , etc. It would be
great if have that committed, documented and implemented in the PHP client.
If there's anything that should be modified there, please let me know.

Dejan Bosanac

On Wed, Jan 23, 2008 at 10:07 PM, Dejan Bosanac <> wrote:

> > 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.
> Fixed.
> > 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
> values
> jms-byte
> jms-object-xml
> jms-object-json
> jms-map-xml
> jms-map-json
> 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
> compatible)?
> --
> Dejan Bosanac

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message