Hi Lowry, good to hear that the suggested workaround worked for you. Regarding your question of using WSDLs at the server side endpoint, the purpose of using a WSDL is to do the operation checking and some special handling based on the determined operation and also to provide a way for the consumer to get the typed interface information (i.e., retrieving the WSDL from the endpoint). In your case, you need neither of these, so you could just simply set up your endpoint using the generic provider mode (i.e., omitting the wsdlURL and serviceClass properties of the endpoint).
In this case, the message will be transformed using dxf's transform feature and directly transferred to your camel route where you can do further modification necessary and set the operationName header to match the operation at the outbound endpoint. regards, aki 2014-07-11 17:23 GMT+02:00 Lowry <[email protected]>: > Hi Aki, > Yes, you understand my scenario and my struggles well. The setup you > describe does seem to be an option. > client(wsdl1) --> EP1(wsdl2)/trans--camel-route- EP2(wsdl2)--> > service(wsdl2) > The only issue i have with this is that, while the incoming request (WSDL1 > versus WSDL2) is pretty similar, the response from backend service (WSDL2) > is quite different from the response expected by client (WSDL1). > Response requires quite a bit of manipulation. After invoking the backend > service, the response adhering to WSDL2 propogates back through my route. > Transforming the response from WSDL2 to WSDL1 requires some enrichment from > external system and more work than the CXF Transform feature is capable of. > So much manipulation that I'd like to be able to perform some of this from > the camel route - after the call to backend service (but before message > passes back through EP1 and response sent back to client.) > > With the setup you describe, If I do this tranformation in Camel route, I > assumed things would blow up when modified response hits EP1 on the way back > to client, but i found that is not the case. The EP1 will pass the response > back (malformed according to WSDL2) to client without the operation/binding > mis-matching I see on the way in if i send a malformed request. So i think > the solution you suggest works for my scenario. Thanks! > > I'm curious, In order to use of CXF transform easier within Camel.. Is there > any way to disable requirement that operation/binding match in CXFEndpoint > on incoming requests? That way i could disable this requirement at the > Endpoint so i could freely apply tranform into any format at the endpoint > and it wouldn't blow up. Otherwise I can only transform into something that > conforms with the WSDL the endpoint is tied to. Although in doing so I > realize I may be abusing somewhat the use-case this feature is intended for. > Thanks, > -Lowry > > > > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/cxf-transform-feature-for-Declarative-transform-in-camel-route-tp5746295p5746339.html > Sent from the cxf-user mailing list archive at Nabble.com.
