2015-01-22 10:07 GMT+01:00 Dirk Lattermann - expertplace <dirk.latterm...@expertplace.de>: > Hi Aki, > > it was not working initially because I tried to use the WSDL for namespace A. > CXF could not process the message because it was transformed to namespace B > too early.
okay. That means, it didn't even get to the out chain. The transformation occurs while reading the data for the inbound and while writing the data for the outbound. So if you have mapping A->B at the inbound and B->A at the outbound, the logical interface is B and hence the endpoint needs to be configured with WSDL. > > For the second point, the situation is like this: > > we have old clients and old services that exchanged messages in namespace A. > Now, for some reason beyond our influence, the web service has to change the > namespace to B, and our routing should make this change transparent to the > old clients (as well as support new clients that use the new namespace B). We > don't know if some of the old clients depend on the old A WSDL in the > standard place ".../service?wsdl" instead of using a local version -- in > other projects, I have seen clients that do. So, to be on the safe side, we'd > like to provide the old namespace WSDL for the service. But how can this be feasible when you are using the same endpoint and the same WSDL query? How do you decide which WSDL to return? regards, aki > > Thanks again, > Dirk > > -----Ursprüngliche Nachricht----- > Von: Aki Yoshida [mailto:elak...@gmail.com] > Gesendet: Mittwoch, 21. Januar 2015 15:14 > An: users@camel.apache.org > Cc: Sergey Beryozkin > Betreff: Re: Camel-CXF: Problems transforming namespace of incoming message > > Hi Dirk, > The transform itself should actually take place with the original > interceptor, as the actual output object is replaced with the > stax-transform'ed XMLStreamWriter regardless of its role. So, I am not sure > why your scenario was not working initially. But I am not sure why the > special requester role handling that you mentioned is there. > Maybe Sergey knows it? > > I don't quite follow your second point. Your consumer endpoint uses WSDL-B > and it can accept the B's namespace and in addition, as the transform feature > configured, it can accept the A's namespace. The transform feature makes sure > that the messages are forwarded using the B's namespace so that they matche > the service interface. If you need WSDL-A, you can host this file somewhere > else. So, I am not familiar with your use case. The transform feature is > typically used as a workaround to support those legacy clients that had the > WSDL from elsewhere that don't match the actual service's WSDL.So, the actual > endpoint doesn't have to provide the alternative WSDL. > > regards, aki > > 2015-01-21 8:35 GMT+01:00 Dirk Lattermann - expertplace > <dirk.latterm...@expertplace.de>: >> Hi, >> >> thanks for your answer! >> >> The intention is different: >> >> Working routing is: >> >> from CXF-B(1) --> (if ..some condition..) --> to CXF-B(2) on >> different host >> >> additional, a namespace mapping is needed: >> >> from CXF-A --> namespace mapping A to B --> to CXF-B(1) so that >> above route is taken >> >> the "namespace mapping A to B" must include mapping the response back from >> namespace B to A. >> >> What I have working or the mapping is an consuming endpoint servicing the B >> namespace (not good because it offers the wrong WSDL to the client), >> configured with StaxTransformationFeature with inTransformElements >> (namespace A to B). >> For the response, StaxTransformationFeature with outTransformElements >> doesn't work: digging in the source I found that >> TransformationOutInterceptor has a condition that prevents transforming >> responses. Only outgoing requests are mapped (that is, in producer mode). >> Curiously, the TransformationInInterceptor doesn't have this restriction. >> >> I solved this by copying the TransformationOutInterceptor into a new class >> and removing the if condition in line 100. Then, I added this new class as >> an outInterceptor to the endpoint. Now the mapping works for the requests >> and the responses! >> >> The only drawback: my incoming mapping endpoint uses the wrong WSDL file >> (for namespace B instead of namespace A). >> Is there a Phase in the CXF processing to which the >> TransformationInInterceptor could be attached so that CXF wouldn't complain >> about a namespace mismatch when using WSDL for namespace A and transforming >> the incoming message to namespace B? >> >> Thank you, >> Dirk >> >> >> -----Ursprüngliche Nachricht----- >> Von: Aki Yoshida [mailto:elak...@gmail.com] >> Gesendet: Dienstag, 20. Januar 2015 11:10 >> An: users@camel.apache.org >> Betreff: Re: Camel-CXF: Problems transforming namespace of incoming >> message >> >> I don't think the http endpoint can be used to bridge typical soap >> webservice calls, as there are some mismatches in the behavior between the >> soap protocol and the plain http protocol. >> >> If I understand your scenario, you want to do something like from-cxf:A ---> >> to-cxf:A if ...some condition... >> from-cxf:A ----> to-cxf:B if ...some condition... >> and cxf:A-> cxf:B requires a minor namespace replacement, no? >> >> In that case, you can just use the PAYLOAD mode for all the cxf endpoints >> and configure the transform feature at the to-cxf:B endpoint to replace the >> namespace. >> >> >> >> >> 2015-01-19 17:29 GMT+01:00 Dirk Lattermann - expertplace >> <dirk.latterm...@expertplace.de>: >>> Hello, >>> >>> we need to build a proxy for an external request/reply SOAP web service. >>> This same service must be offered both unmodified (namespace A) and with a >>> different namespace B in the message schema. In both cases, some additional >>> routing decisions must be taken. >>> >>> For this, we have defined a CXF producer endpoint (using cxf:cxfEndpoint) >>> in POJO message format that addresses the external service, using their >>> WSDL (namespace A). The unmodified proxy on the consuming (input) side is >>> also a CXF endpoint in POJO format, using the same WSDL. A route forwards >>> (after some routing decisions) from this to the external service; this >>> works. >>> >>> To offer the service with a different namespaces, we tried several >>> approaches without success. >>> >>> One possibility seems to be a CXF consumer endpoint in MESSAGE message >>> format that uses a StaxTransformationFeature to modify the namespace from B >>> to A. >>> This endpoint uses a modified WSDL with namespace B instead of A. It must >>> use MESSAGE, not POJO, because the WSDL file with the modified message >>> namespace B would not match the transformed message in namespace A, which >>> results in a parsing (JAXB) exception from CXF. We would like to send the >>> transformed message to our own namespace A consumer endpoint to run through >>> the normal routing decisions mentioned above. We cannot use the POJO >>> endpoint because the message is in MESSAGE format. So, we tried POSTing >>> the message using the HTTP component: >>> >>> <route id="cxf-admin-nsmap-route"> >>> <from uri="cxf:bean:fc-admin-service"/> >>> <to >>> uri="http://${fc.endpoint.host}:${fc.endpoint.port}/${fc.admin_cxf_ns >>> m >>> od.endpoint.path}"/> >>> </route> >>> >>> This fails with >>> >>> Invalid uri: /fc/admin. If you are forwarding/bridging http >>> endpoints, then enable the bridgeEndpoint option on the endpoint: >>> Endpoint[http://$%7Bfc.endpoint.host%7D:$%7Bfc.endpoint.port%7D/$%7Bf >>> c >>> .admin_cxf_nsmod.endpoint.path%7D] >>> >>> /fc/admin is the path for the incoming request (defined by >>> cxf:bean:fc-admin-service), not the one defined in the to-uri >>> (${fc.admin_cxf_nsmod.endpoint.path}). >>> >>> We tried to add the bridgeEndpoint property as in >>> >>> <route id="cxf-admin-nsmap-route"> >>> <from uri="cxf:bean:fc-admin-service"/> >>> <to >>> uri="http://${fc.endpoint.host}:${fc.endpoint.port}/${fc.admin_cxf_ns >>> m od.endpoint.path}?bridgeEndpoint=true"/> >>> </route> >>> >>> This fails with >>> >>> org.apache.commons.httpclient.URIException: Invalid authority >>> >>> >>> A different approach where we tried XSLT to transform the namespaces, use >>> JAXB unmarshalling and create a MessageContentsList to convert the message >>> into POJO format by hand which can then be sent into the routing decision >>> route directly leads to difficulties with marshalling the response back: >>> the namespace prefix for the type names in (as xsd in >>> xsi:type="xsd:string") gets lost. On top, this approach seems still uglier >>> an less maintainable than the first one I described. >>> >>> What might be a working and clean, simple, maybe even elegant solution to >>> this problem? It's simply mapping a message in one namespace to another! >>> >>> Thank you, >>> Dirk >>> >>>
