I've finally got my hands on this and implemented it in a way we discussed it here. Patch is uploaded to the old issue (https://issues.apache.org/activemq/browse/AMQ-943).
Here are a couple of notes and questions: - I've used the "transformation" header to lookup the appropriate frame translator - In the current implementation there is a XStreamFrameTranslator which handles basic XML and JSON transformations - 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 (https://issues.apache.org/activemq/browse/AMQ-1493) we can use it as normal. - 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. - 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 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. 1. make XBeanBrokerService ApplicationContextAware 2. make StompTransportFactory BrokerServiceAware 3. when creating transports if the transport factory implements BrokerServiceAware it is passed to it 4. then if the broker service is application context aware we can extract it in the factory. any better ideas? When we sort this out, we can make OXM translator that could use well configured XStream, Castor, XMLBeans, etc. All comments are welcomed. Thanks -- Dejan Bosanac www.scriptinginjava.net On Dec 15, 2007 6:59 PM, Hiram Chirino <[EMAIL PROTECTED]> wrote: > > On Dec 15, 2007 11:11 AM, Dejan Bosanac <[EMAIL PROTECTED]> wrote: > > Hi Hiram > > > > On Dec 14, 2007 6:40 PM, Hiram Chirino <[EMAIL PROTECTED]> wrote: > > > I personally think that a STOMP client should request a transformation > > > strategy. For example on a subscribe, he could do > > > > > > SUBSCRIBE > > > destination: /queue/foo > > > transformation: jms-json > > > ack: client > > > > > > And on the reverse side, The send could look like: > > > > > > SEND > > > destination:/queue/a > > > transformation: jms-json > > > > > > ["Hello World",1] > > > ^@ > > > > > > And have the Stomp transport handle those "transformation" headers by > > > looking up the "jms-json" transformation in the spring context. This > > > would allow the broker to have extensible transformations. And the > > > looked up object would just need to implement the following interface: > > > > > > http://activemq.apache.org/maven/activemq-core/apidocs/org/apache/activemq/transport/stomp/FrameTranslator.html > > > > That's great. This idea has been discussed on the list some time ago > > and I think it's a good approach. I though that maybe it could be > > useful for other transports as well, but you're probably right that we > > should keep this Stomp-related for now. > > > > A few questions about your idea: > > > > * Maybe it would be better to have "transfomers" registered at boot > > time, rather then doing lookups when message arrives? If so, there has > > to be a mechanism to configure Stomp transport with transformers that > > will be used. What method do you propose for this, if any? Maybe > > StompTransportFactory could do lookup on init? > > Well the one up side to doing the lookup per send is that the sender > can choose different transformation strategies depending on the > message he is sending. Perhaps he got a JSON message in, so he sends > using the json transformation. Perhaps he got a XML message so he > sends it using an XML transformation etc. > > The look up cost should be cheap but if you think perhaps it's an > expensive operation, we could cache lookups. The easiest way to make > this extensible and easy to get stuff registered for lookup is to use > the FactoryFinder [1] to lookup implementations by searching the > META-INF directories. For examples how we use this see the impl of > DiscoveryAgentFactory [2] > > [1] > http://activemq.apache.org/maven/activemq-core/apidocs/org/apache/activemq/util/FactoryFinder.html > [2] > https://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/transport/discovery/DiscoveryAgentFactory.java > > > > * We have to allow users to add their "domain" classes to the amq > > classpath, as I guess the most of them will want to transform XML/JSON > > to objects of those classes. That's not a problem for brokers embedded > > in applications, but I guess they could do that in the off-the-shelf > > broker by adding appropriate JAR to the lib/ folder? > > > > Yep that's the standard way we expand functionality in the broker. > > > > > > > > > Just need to find someone who is willing to take a stab at enhancing > > > the stomp transport so that it does those "transfromation" header > > > handling logic. And add a few more interesting implementations of > > > FrameTranslator. > > > > No problem about that. I'll invest some time in this, both in amq and > > PHP Stomp client. But before that I thought I handle authentication > > for Stomp as it is far more important IMHO. I'll start with this patch > > (https://issues.apache.org/activemq/browse/AMQ-1272) add test cases > > and implement proper behavior. > > > > That's awesome! > > > > > Cheers > > -- > > Dejan Bosanac > > www.scriptinginjava.net > > > > > > > -- > Regards, > Hiram > > Blog: http://hiramchirino.com > > Open Source SOA > http://open.iona.com >
