Awesome! On Jan 15, 2008 6:47 AM, Dejan Bosanac <[EMAIL PROTECTED]> wrote: > 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
Perfect! > > - 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. > 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. > - 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. > > - 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. > - 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. > 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 > > > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
