cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cogitate <>
Subject Re: cxf-2.4.0 pattern match StaxTransformFeature?
Date Tue, 10 May 2011 04:20:11 GMT
>Is there any reason you are not using inTransformElements property ?
actually , i didn't get around to doing this since i was testing the
outgoing functionality but , yes this is something i need to do. 

i configure an incoming XML Namespace Interceptor that will add a namespace
to the root element of the incoming xml if the xml did not already have the
namespace. if it did , then it's pass through.

> I think updating the feature to check wildcards will be
> starightforward, I'd appreciate though if you could explain a bit more
> what happening in the following two cases.

> Client makes an invocation and drops the output namespaces. What happens
> when:

> normal response is sent back ?
> exceptional response is sent back ?

> I'd just like to understand better how dropping namespaces using
> wildcards can help if you may need some explicit knowledge for
> response data be read, sorry if I'm a bit slow :-)

> Showing some sample in/out XML payloads can help :-)

so on the outgoing route , i have the following :

<ns2:WebGet xmlns:ns3=""

after transformation through the outTransformElements i get the following -
this is the xml that goes to the server.

now on the way back i get the following :
<WebGetResponse xmlns="">

notice the root element "WebGetResponse" has a default namespace that's
applied to all the nodes of the xml. If i call a different service i get
something like the following back :
this is when my custom inXMLNSInterceptor will add the namespace
xmlns="" and transform the incoming xml to
that which the jaxb binding object requires.

so , yes, if i were doing the above using inTransformElements of the
StaxTransformFeature i'd require to add some conditions ( whether to add the
namespace or not )

the fault error codes are SOAPFaults ( thankfully returned by the vendor)
and thus get caught by the SOAPFaultInterceptors that are part of the CXF
JAX-WS stack to throw the exception as defined in the SEI.


> Thanks, Sergey

View this message in context:
Sent from the cxf-user mailing list archive at

View raw message