cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: cxf-2.4.0 pattern match StaxTransformFeature?
Date Tue, 10 May 2011 09:36:12 GMT

Please see comments inline

On Tue, May 10, 2011 at 5:20 AM, cogitate <> wrote:
>>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=""
> xmlns:ns2=""><ns2:Buffer><ns2:Name>ROUTE</ns2:Name></ns2:Buffer></ns2:WebGet>
> after transformation through the outTransformElements i get the following -
> this is the xml that goes to the server.
> <WebGet><Buffer><Name>ROUTE<Name><Buffer><WebGet>
> now on the way back i get the following :
> <WebGetResponse xmlns="">
>  <AllRoutes>
>       <Route1/><Route2/><Route3/>...
>  </AllRoutes>
> </WebGetResponse>
> 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 :
> <WebGetResponse>
>  <AllRoutes>
>       <Route1/><Route2/><Route3/>...
>  </AllRoutes>
> </WebGetResponse>
> 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 )

You can do the following with StaxTransformFeature in the inbound chain:
* : {""}*

Which reads as "Have all incoming elements qualified with
"" namespace".

Here are two quick tests I did:

InputStream is = new ByteArrayInputStream("<test
XMLStreamReader reader = StaxUtils.createXMLStreamReader(is); reader =
new InTransformReader(reader,
                                       null, false);

ByteArrayOutputStream bos = new ByteArrayOutputStream();
StaxUtils.copy(reader, bos);

This prints:

<ps1:test xmlns:ps1="http://bar"><ps1:super/></ps1:test>

Providing "<test><super/></test>" to the above code also results in:

<ps1:test xmlns:ps1="http://bar"><ps1:super/></ps1:test>

In the former case all the elements are explicitly qualified which is
equivalent to having a default namespace.

If you had


coming in but only needed 'test' qualified then you'd do

test : {http://bar}test

which would leave 'super' unqualified

So you might want to consider just using inTransformElements.

But as you see, we need to know on the inbound side the namespace or
namespaces which may need to be added.
So the point I'm trying to make is that yes we can update the feature
to drop the namespaces using wildcards but I think it will only make
sense if we have oneway invocations to deal with, otherwise it is just
faster (for the feature) to do the exact namespace matches.

I may add some basic support for it though, say if the last character
of the namespace value is '*' then do String.matches() otherwise
equals()...So '{*}* : *' will work too.

thanks, Sergey

> 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.
> HTH,
> thanks
>> Thanks, Sergey
> --
> View this message in context:
> Sent from the cxf-user mailing list archive at

Sergey Beryozkin

Application Integration Division of Talend

View raw message