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 Fri, 23 Jan 2015 07:48:39 GMT
Hi Aki, please see below.

> -----Urspr√ľngliche Nachricht-----
> Von: Aki Yoshida [mailto:elakito@gmail.com]
> Gesendet: Donnerstag, 22. Januar 2015 22:04
> An: users@camel.apache.org
> Betreff: Re: Camel-CXF: Problems transforming namespace of incoming
> message
> 
> 2015-01-22 10:07 GMT+01:00 Dirk Lattermann - expertplace
> <Dirk.Lattermann@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

I'm confused here. I was talking about the processing of the incoming request. The out chain
is responsible for the response?
But yes, you're right, the CXF component cannot produce a Camel message in this case, because
from its perspective, the message is in namespace B, not A. 

> 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.

Yes, I understand that now. I was wondering if the transformation can be placed later in the
chain to enable configuring the WSDL for namespace A, but I doubt it is possible.


> 
> >
> > 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?

I'm offering two endpoints: one for namespace B without mapping and one for namespace A with
mapping which forwards its processing to the namespace B endpoint. Right now, the forwarding
even happens over the net, leaving the camel route; I have to refactor that to have both endpoints
routed to the same subroute.

Dirk
Mime
View raw message