2014-07-10 23:04 GMT+02:00 Sergey Beryozkin <[email protected]>: > HI, > > On 10/07/14 16:21, Lowry wrote: >> >> I have a camel route that starts with a cxfEndpoint1 (consumer) that works >> as >> a CXF server and represents the interface defined in wsdl1. The route is a >> pass-through route that sends to a backend web service using CXFEndpoint2 >> (producer) pointing to wsdl2. >> >> The interface for wsdl1 (incoming) is slightly different (different >> element >> names, and namespace) than the outgoing wsdl2 interface. We need to >> introduce transformation in between that transforms message. >> >> I'd like a strategy for introducing transformation that is declarative and >> doesn't force me to write java DOM code or XSLT. I found the CXF transform >> feature and it looked promising. I'm using it in my route. But i'm >> having >> some issues. >> >> Is it designed for such a use-case? The problem i have is that the >> transform seems to occur on entry before the message "hits" CXFEndpoint1. >> So >> if I apply the transform feature to the CXFEndpoint1 (listener), and the >> transform defines namespace or element changes (goal is to conform the >> message to wsdl2) then I get an exception that the operation name or >> namespace is incorrect. I'm guessing its because by transforming the >> message at CXFEndpoint1 at an interceptor that occurs before the message >> is >> validated against WSDL1, so it breaks. >> > You can have individual Transform interceptors used instead of the feature, > and have them run in a CXF Phase which would be done after a WSDL11 > validation, not sure what phase that should be, but you can do a fine-level > control of when the feature is applied >
I am not very sure if there is some issue in the operation/binding matching in the way how Lowry uses the WSDLs and I think he might want to configure his route differently to avoid any issue while using the out of the box transform feature. Basically, he has client --> EP1 --camel-route- EP2 --> service and his original set up was something like this client(wsdl1) --> EP1(wsdl1)/trans--camel-route- EP2(wsdl2)--> service(wsdl2) and he was having the binding/operation mismatch issue at EP1. my suggestion would be to use wsdl2 and EP1 so that the transformed message matches the assigned wsdl. client(wsdl1) --> EP1(wsdl2)/trans--camel-route- EP2(wsdl2)--> service(wsdl2) we have to make sure that the client is using wsdl1 that that has been retrieved and available locally. in the future, we might want to consider providing a feature to dynamically modify the assigned wsdl using the transform rules ;-) regards, aki > HTH, Sergey > > > > >> So i'm coming to the conclusion that the transform feature is not a good >> way >> to achieve my goal of a generic all-purpose declarative tranfomration >> strategy in a camle pass through route from one CXFEndpoint (consumer) to >> another CXFEndpoint (producer). >> >> Can someone deny or confrm my thoughts on this, or recommend an approach >> to >> do this type of declarative mapping / tranform simimilar to CXF transform >> feature that would allow me to accomplish? >> >> >> >> >> >> -- >> View this message in context: >> http://cxf.547215.n5.nabble.com/cxf-transform-feature-for-Declarative-transform-in-camel-route-tp5746295.html >> Sent from the cxf-user mailing list archive at Nabble.com. >> > > > -- > Sergey Beryozkin > > Talend Community Coders > http://coders.talend.com/ > > Blog: http://sberyozkin.blogspot.com
