You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by cogitate <mo...@gmail.com> on 2011/07/08 05:47:28 UTC
Re: cxf-2.4.0 pattern match StaxTransformFeature?
ok - just to close the loop .
what was happening is specific to cxf-2.4.0 and it's a bug that's been fixed
in cxf-2.4.1-SNAPSHOT as given below.
http://cxf.547215.n5.nabble.com/quot-Stream-is-closed-quot-Exception-when-upgrade-from-CXF-2-3-3-to-CXF-2-4-0-td4385277.html
cxf stream is closed early
very very difficult to debug/find.
btw Sergei :
do you know if using TransformFeature/InTransformElements i can turn off the
prefix "ps1:" ? so that it makes it xmlns="<namespace>" and applies that to
all elements?
regards
--
View this message in context: http://cxf.547215.n5.nabble.com/cxf-2-4-0-pattern-match-StaxTransformFeature-tp4381005p4563318.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: cxf-2.4.0 pattern match StaxTransformFeature?
Posted by cogitate <mo...@gmail.com>.
Sergei :
my apologies - and thank you for the correction !!
i completely agree with you , for the input what we have currently suffices
( even adding of prefixes within cxf chain interceptors poses no threats as
jaxb impls in cxf do what's required! )
You abzolutellly Rock!!!
if you ever do make it to the bay-area i would love to get you coffee/lunch
and meet up with you to pick your brains!
regards
--
View this message in context: http://cxf.547215.n5.nabble.com/cxf-2-4-0-pattern-match-StaxTransformFeature-tp4381005p4816957.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: cxf-2.4.0 pattern match StaxTransformFeature?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 17/09/11 18:42, cogitate wrote:
> hi sergei:
> many thanks for the feature to drop outgoing default namespaces.
Actually, I did not add that feature as a follow-up to our conversation,
it was possible to drop default or non-default namespaces from the get
go, but I update the out handler to optionally use a default namespace
when writing out namespaces. Having it for out messages can make sense
in some cases...
> so - for incoming messages what's the complexity of dropping namespaces?
> i have an inInterceptor that passes the incoming messages through an xslt (
> for certain types of payload ) that drops all prefixes and namespaces.
>
> why can't we have this?
>
If you are referring to dropping namespaces then you can do it right
now. Having some leftover non-default namespace declarations can't
prevent JAXB from properly reading the payload
Sergey
> regards,
> -cogitate
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/cxf-2-4-0-pattern-match-StaxTransformFeature-tp4381005p4814256.html
> Sent from the cxf-user mailing list archive at Nabble.com.
Re: cxf-2.4.0 pattern match StaxTransformFeature?
Posted by cogitate <mo...@gmail.com>.
hi sergei:
many thanks for the feature to drop outgoing default namespaces.
so - for incoming messages what's the complexity of dropping namespaces?
i have an inInterceptor that passes the incoming messages through an xslt (
for certain types of payload ) that drops all prefixes and namespaces.
why can't we have this?
regards,
-cogitate
--
View this message in context: http://cxf.547215.n5.nabble.com/cxf-2-4-0-pattern-match-StaxTransformFeature-tp4381005p4814256.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: cxf-2.4.0 pattern match StaxTransformFeature?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On Mon, Jul 18, 2011 at 12:06 AM, cogitate <mo...@gmail.com> wrote:
> thanks sergei.
> in the case of enterprise where a payload has just one namespace, a prefix
> seems redundant.
> and yes , the response payload is huge..:(
>
> how does one add a defaultNamespace property for incoming messages?
>
I've added a defaultNamespace property to TransformOutInterceptor so
for large payloads
it will be possible to set this property and save a bit on dropping
the prefixes.
Note, it's not possible to do it for incoming payloads (with the help
of InTransformReader)
Cheers, Sergey
> regards
>
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/cxf-2-4-0-pattern-match-StaxTransformFeature-tp4381005p4597609.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com
Re: cxf-2.4.0 pattern match StaxTransformFeature?
Posted by cogitate <mo...@gmail.com>.
thanks sergei.
in the case of enterprise where a payload has just one namespace, a prefix
seems redundant.
and yes , the response payload is huge..:(
how does one add a defaultNamespace property for incoming messages?
regards
--
View this message in context: http://cxf.547215.n5.nabble.com/cxf-2-4-0-pattern-match-StaxTransformFeature-tp4381005p4597609.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: cxf-2.4.0 pattern match StaxTransformFeature?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On Fri, Jul 8, 2011 at 4:47 AM, cogitate <mo...@gmail.com> wrote:
> ok - just to close the loop .
> what was happening is specific to cxf-2.4.0 and it's a bug that's been fixed
> in cxf-2.4.1-SNAPSHOT as given below.
> http://cxf.547215.n5.nabble.com/quot-Stream-is-closed-quot-Exception-when-upgrade-from-CXF-2-3-3-to-CXF-2-4-0-td4385277.html
> cxf stream is closed early
>
> very very difficult to debug/find.
>
Thanks for the confirmation
> btw Sergei :
> do you know if using TransformFeature/InTransformElements i can turn off the
> prefix "ps1:" ? so that it makes it xmlns="<namespace>" and applies that to
> all elements?
>
Enforcing a default namespace at the writer level is tricky. We can
have a complex document going out with many namespaces, possibly with
the existing default namespace and say we just need to update a
namespace on one of the nodes only.
Do you need this for some specific reasons, ex, concerned about the
propagation of prefixes in a large doc ?
I guess one option is to add a defaultNamespace property which can be
used to emit a chosen namespace as the default one
Sergey
> regards
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/cxf-2-4-0-pattern-match-StaxTransformFeature-tp4381005p4563318.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com