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, 16 Jan 2008 08:40:41 GMT
Hi Hiram

On Jan 15, 2008 8:42 PM, Hiram Chirino <> wrote:
> > - For JSON conversion to work we need to use 1.2.2 version of XStream,
> > which is currently hardcoded in the pom, but if we apply this change
> > ( we can use it as
> > normal.
> >
> Sure.. We can get those applied.  BTW when you submitted those patches
> you did not click the check box that said your granting the ASF a lic.
> to use your patch.  If you get a chance please reattach the patches
> with those check boxes clicked.

I've just uploaded AMQ-1493 patch again with the grant, the AMQ-943
had the license in the first place so it should be all good now. Sorry
about that.

> > - the implementation ignores any errors that could happen during
> > transformation (unknown translator, wrong xml, etc) and uses legacy
> > translator in those cases. I think this is desired behavior, but if
> > you think different it could be easily changed.
> 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.

That's great idea.

> >
> > - the transformation is done when user sends or subscribes with the
> > "transformation" header. Also, if the JMS client sends a message with
> > "transformation" header set it will be transformed before delivered to
> > the STOMP client even if it has not subscribed with the
> > "transformation" header. The subscription "transformation" has a
> > priority against message "transformation" in case that both are set
> >
> 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.

Makes sense. Will change that.

> > - the open question is how to add a support configuration of XStream
> > (and other marshallers) in the Spring context. The current
> > implementation is nice, but to be really useful people needs (or at
> > least I do) to have configured XStream to handle desired XML(JSON)
> > format. The transport layer is not easily exposed to the spring
> > application context. I found one solution that could work, but is not
> > so elegant.
> >
> This sounds fine to me!  Please make it a separate patch.


> Oh an BTW..  once we get this committed..
> I'd like to work on making the default jms-xml transformation support
> all the JMS message types, especially MapMessage.

Definitely, converting arrays, hashtables, etc to map messages would
be very useful.

I think it would be best to commit these patch and then I'll continue
to work further on Spring support, other transporters and message
types from there. I'll also document it in the AMQ and Stomp wikis and
create a "reference implementation" in a PHP client.

Dejan Bosanac

View raw message