camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk Lattermann - expertplace <Dirk.Latterm...@expertplace.de>
Subject AW: Camel-CXF: Problems transforming namespace of incoming message
Date Wed, 21 Jan 2015 07:35:54 GMT
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:elakito@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.Lattermann@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_nsm
> 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/$%7Bfc
> .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_nsm
> 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
>
>
Mime
View raw message