Patches applied Thanks! Keep em coming :) On Jan 16, 2008 3:40 AM, Dejan Bosanac <[EMAIL PROTECTED]> wrote: > Hi Hiram > > On Jan 15, 2008 8:42 PM, Hiram Chirino <[EMAIL PROTECTED]> 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 > > > (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. > > 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. > > Great. > > > 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. > > > Thanks > -- > Dejan Bosanac > www.scriptinginjava.net >
-- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
