cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cogitate <monish.u...@gmail.com>
Subject Re: cxf-2.4.0 pattern match StaxTransformFeature?
Date Tue, 10 May 2011 15:07:00 GMT
Hi Sergey

thanks for showing me what to do with the incoming message - on a side note
is it not
possible to have no prefixed based xml for incoming too , with just
defaultNamespace ?

i know cxf's parsers will handle the xml example you had...but if the xml is
huge the readability 
is great without a prefix and namespace attached to each element.

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

...probably makes sense , though i don't see the harm of having the feature
and let
developers handle the incoming xml as they want. besides we really do
separate
outTransformElements and inTransformElements ... so.... we can use them in a
mutually
exclusive way. 




--
View this message in context: http://cxf.547215.n5.nabble.com/cxf-2-4-0-pattern-match-StaxTransformFeature-tp4381005p4384723.html
Sent from the cxf-user mailing list archive at Nabble.com.

Mime
View raw message