You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Benson Margulies <bi...@gmail.com> on 2009/12/07 12:18:39 UTC
Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in text to output"
XML prohibits that character. you cannot sent it in an xsd:string.
On Dec 7, 2009, at 6:10 AM, Pavel <pa...@gmail.com> wrote:
> Hello,
>
> I'm facing an issue with CXF + WSS4JOutInterceptor.
> Seems like it is unable to hadle strings that contain characters
> with hex
> code <0x20; Client fails to send request with the following stacktrace
>
> javax.xml.ws.soap.SOAPFaultException: Problem writing SAAJ model to
> stream
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
> 146)
> *at $Proxy125.isStayQualified(Unknown Source)* << that is my
> client
> ...
> Caused by: com.ctc.wstx.exc.WstxIOException: *Invalid white space
> character
> (0x1) in text to output*
> at
> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters
> (BaseStreamWriter.java:511)
> at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:434)
> at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:412)
> at
> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor
> $SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:197)
> at
> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor
> $SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:158)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept
> (PhaseInterceptorChain.java:236)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261)
> at org.apache.cxf.frontend.ClientProxy.invokeSync
> (ClientProxy.java:73)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
> 124)
> ... 30 more
> Caused by: java.io.IOException: Invalid white space character (0x1)
> in text
> to output
> at com.ctc.wstx.sw.XmlWriter.throwInvalidChar(XmlWriter.java:545)
> at
> com.ctc.wstx.sw.BufferingXmlWriter.writeCharacters
> (BufferingXmlWriter.java:531)
> at
> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters
> (BaseStreamWriter.java:509)
> ... 40 more
>
>
> Requests work fine though if I don't use WSS4JOutInterceptor.
> Problematic
> chars get escaped as &#XX.
>
> I tried that with both CXF 2.2.0-fuse and 2.2.5.
> Is there some sort of configuration required to avoid that issue?
>
>
> Thanks,
> Pavel
Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in text to output"
Posted by Benson Margulies <bi...@gmail.com>.
not all paths notice this. however, if your data dosen't have this
char in it, we have some other problem.
On Dec 7, 2009, at 7:08 AM, Pavel <pa...@gmail.com> wrote:
> But that's not me, it is CXF that produces XML representation of that
> character. I expect CXF to take care of marshalling specifics,
> including
> proper escaping of special characters.
>
> Moreover, as I mentioned, CXF does that work well unless/until
> security
> interceptor comes into play.
>
> So obviously there is an XML representation for the data I want to
> send, and
> I'm back to may question - what is/whether there is a way to make
> security
> interceptor handle 0x1 properly?
>
> Thanks,
> Pavel
>
> On Mon, Dec 7, 2009 at 1:18 PM, Benson Margulies <bimargulies@gmail.com
> >wrote:
>
>> XML prohibits that character. you cannot sent it in an xsd:string.
>>
>>
>> On Dec 7, 2009, at 6:10 AM, Pavel <pa...@gmail.com> wrote:
>>
>> Hello,
>>>
>>> I'm facing an issue with CXF + WSS4JOutInterceptor.
>>> Seems like it is unable to hadle strings that contain characters
>>> with hex
>>> code <0x20; Client fails to send request with the following
>>> stacktrace
>>>
>>> javax.xml.ws.soap.SOAPFaultException: Problem writing SAAJ model
>>> to stream
>>> at
>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
>>> 146)
>>> *at $Proxy125.isStayQualified(Unknown Source)* << that is my
>>> client
>>> ...
>>> Caused by: com.ctc.wstx.exc.WstxIOException: *Invalid white space
>>> character
>>> (0x1) in text to output*
>>> at
>>>
>>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters
>>> (BaseStreamWriter.java:511)
>>> at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:434)
>>> at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:412)
>>> at
>>>
>>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor
>>> $SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:197)
>>> at
>>>
>>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor
>>> $SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:158)
>>> at
>>>
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept
>>> (PhaseInterceptorChain.java:236)
>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483)
>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309)
>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261)
>>> at org.apache.cxf.frontend.ClientProxy.invokeSync
>>> (ClientProxy.java:73)
>>> at
>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
>>> 124)
>>> ... 30 more
>>> Caused by: java.io.IOException: Invalid white space character
>>> (0x1) in
>>> text
>>> to output
>>> at com.ctc.wstx.sw.XmlWriter.throwInvalidChar(XmlWriter.java:545)
>>> at
>>>
>>> com.ctc.wstx.sw.BufferingXmlWriter.writeCharacters
>>> (BufferingXmlWriter.java:531)
>>> at
>>>
>>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters
>>> (BaseStreamWriter.java:509)
>>> ... 40 more
>>>
>>>
>>> Requests work fine though if I don't use WSS4JOutInterceptor.
>>> Problematic
>>> chars get escaped as &#XX.
>>>
>>> I tried that with both CXF 2.2.0-fuse and 2.2.5.
>>> Is there some sort of configuration required to avoid that issue?
>>>
>>>
>>> Thanks,
>>> Pavel
>>>
>>
>
>
> --
> Best regards,
> Pavel
Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in text to output"
Posted by Daniel Kulp <dk...@apache.org>.
On Tue December 29 2009 5:44:36 pm Pavel wrote:
> I did implement this approach and have not noticed issues so far. I'll
> write back if I notice any.
You can also set a "disable.outputstream.optimization" property on the
endpoint/bus to true to have it disable the direct writing to the outputstream
and always go through the XMLStreamWriter. Should accomplish the same thing
without the overhead of having the SAAJModel created.
Dan
> Pavel
>
> On Tue, Dec 29, 2009 at 1:04 PM, Pavel <pa...@gmail.com> wrote:
> > Hi,
> >
> > I'd like now to spread this behaviour to all endpoints, not just secured
> > ones. Basically, hook that interceptor to CXF bus.
> >
> > And this is because certain consumers use woodstox, or generally
> > speaking, validate content.
> >
> > My understanding is that I need woodstox to kick in for every single
> > request. And the way to do that is to add "SAAJOutInterceptor" explicitly
> > as well. Do you see issues with that approach?
> >
> > Thanks!
> > Pavel
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in
text to output"
Posted by Pavel <pa...@gmail.com>.
I did implement this approach and have not noticed issues so far. I'll write
back if I notice any.
Pavel
On Tue, Dec 29, 2009 at 1:04 PM, Pavel <pa...@gmail.com> wrote:
> Hi,
>
> I'd like now to spread this behaviour to all endpoints, not just secured
> ones. Basically, hook that interceptor to CXF bus.
>
> And this is because certain consumers use woodstox, or generally speaking,
> validate content.
>
> My understanding is that I need woodstox to kick in for every single
> request. And the way to do that is to add "SAAJOutInterceptor" explicitly as
> well. Do you see issues with that approach?
>
> Thanks!
> Pavel
>
Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in
text to output"
Posted by Pavel <pa...@gmail.com>.
Hi,
I'd like now to spread this behaviour to all endpoints, not just secured
ones. Basically, hook that interceptor to CXF bus.
And this is because certain consumers use woodstox, or generally speaking,
validate content.
My understanding is that I need woodstox to kick in for every single
request. And the way to do that is to add "SAAJOutInterceptor" explicitly as
well. Do you see issues with that approach?
Thanks!
Pavel
Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in
text to output"
Posted by Pavel <pa...@gmail.com>.
I implemented #1 from your suggestions, and it seems to work well. Thanks!
On Mon, Dec 7, 2009 at 7:36 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Mon December 7 2009 9:27:36 am Pavel wrote:
> > Ok, I'm a bit lost then, so I'll just state once again what I observed
> > before and read in your responses.
> >
> > A. Input
> > 1. There are whitespace characters with code <0x20, that may come in bean
> > string properties, that are used.
> > 2. By default CXF handles them by quoting into output stream. &#XX.
> Client
> > able to send out the request
>
> This is technically a bug in JAXB, it shouldn't be doing that. It SHOULD
> be
> throwing an exception, but not something I would normally worry about.
>
> > 3. With WSS4JOutInterceptor enabled CXF behaivour changes, exception is
> > thrown (stacktrace available in previous posts)
>
> Actually, it would also change with Aegis or XMLBeans. For JAXB, we
> normally use an optimization to bypass the XMLStreamWriter which is much
> faster, but allows JAXB to encode this case in an invalid way. If we turn
> off the optimization (there is a flag for that) and go through the
> XMLStreamWriter, it would throw the same exception. Again, bug in JAXB.
>
>
> > B. Comments
> > 1. XML 1.0 prohibits these characters.
> > 2. CXF cannot marshall u+0001 in a string. (Although it does in A2).
> > 3. It is up to the app to fix the content somehow.
> > 4. if you have to ship chars like this, you need to push them around as
> > bytes.
> >
> > C. My additional observations.
> > 1. The validation itself comes from the woodstox used by
> > SAAJOutInterceptor.
> > 2. It is WSS4JOutInterceptor that adds
> > SAAJOutInterceptor into the interceptor chain.
>
> There are other use cases as well. Example: having a JAXWS SOAPHandler on
> the chain would also trigger adding it.
>
> > 3. http://jira.codehaus.org/browse/WSTX-223 asks for the ability to turn
> > that validation off, but this issue is "open"/not implemented.
> > 4. Woodstox 4 has an option to replace illegal characters with e.g.
> spaces;
> > see http://www.cowtowncoder.com/blog/archives/2008/12/entry_106.html
> > 5. CXF uses Woodstox 3.x.x
> >
> > Are there any plans for CXF to update to Woodstox 4.x?
>
> CXF trunk (targetting 2.3) is using woodstox 4. The branches SHOULD work
> fine with 4 as well if you want to use 4 instead of 3.x.
>
> > And then expose
> > option to replace/handle these whitespace characters?
> >
> > Or otherwise, could you recommend a way to plug into request/response
> > processing and replace these chars via CXF API?
>
> Well, one option is to write a XMLStreamWriter wrapper that forwards all
> the
> calls to a the original writer except for the writeCharacter methods (and
> probably writeAttribute). Those methods would escape or replace any
> invalid
> content and then call the original. An interceptor running immediately
> after
> the StaxOutInterceptor would take the original XMLStreamWriter and wrapper
> it
> with yours and replace it.
>
> You could also configure in your own XMLOutputFactory that does it as well
> that wouldn't require an interceptor, but you would need to
> override/wrapper
> more methods there as well.
>
> Dan
>
>
> >
> > Thanks,
> > Pavel
> >
> > On Mon, Dec 7, 2009 at 3:19 PM, Benson Margulies
> <bi...@gmail.com>wrote:
> > > cxf cannot marshall u+0001 in a string. the best it could do is throw
> > > sooner. it is up to the app. it is a strange feature of jax-whatever
> that
> > > string values are constrained to XML 1.0 valid chars, but there you
> are.
> > > if you have to ship chars like this, you need to push them around as
> > > bytes.
> > >
> > >
> > > On Dec 7, 2009, at 7:08 AM, Pavel <pa...@gmail.com> wrote:
> > >
> > > But that's not me, it is CXF that produces XML representation of that
> > >
> > >> character. I expect CXF to take care of marshalling specifics,
> including
> > >> proper escaping of special characters.
> > >>
> > >> Moreover, as I mentioned, CXF does that work well unless/until
> security
> > >> interceptor comes into play.
> > >>
> > >> So obviously there is an XML representation for the data I want to
> send,
> > >> and
> > >> I'm back to may question - what is/whether there is a way to make
> > >> security interceptor handle 0x1 properly?
> > >>
> > >> Thanks,
> > >> Pavel
> > >>
> > >> On Mon, Dec 7, 2009 at 1:18 PM, Benson Margulies <
> bimargulies@gmail.com
> > >>
> > >> >wrote:
> > >>
> > >> XML prohibits that character. you cannot sent it in an xsd:string.
> > >>
> > >>> On Dec 7, 2009, at 6:10 AM, Pavel <pa...@gmail.com> wrote:
> > >>>
> > >>> Hello,
> > >>>
> > >>>> I'm facing an issue with CXF + WSS4JOutInterceptor.
> > >>>> Seems like it is unable to hadle strings that contain characters
> with
> > >>>> hex
> > >>>> code <0x20; Client fails to send request with the following
> stacktrace
> > >>>>
> > >>>> javax.xml.ws.soap.SOAPFaultException: Problem writing SAAJ model to
> > >>>> stream
> > >>>> at
> > >>>>
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146
> > >>>>) *at $Proxy125.isStayQualified(Unknown Source)* << that is my
> client
> > >>>> ...
> > >>>> Caused by: com.ctc.wstx.exc.WstxIOException: *Invalid white space
> > >>>> character
> > >>>> (0x1) in text to output*
> > >>>> at
> > >>>>
> > >>>>
> > >>>>
> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java
> > >>>>:511) at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:434)
> at
> > >>>> org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:412) at
> > >>>>
> > >>>>
> > >>>>
> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInter
> > >>>>ceptor.handleMessage(SAAJOutInterceptor.java:197) at
> > >>>>
> > >>>>
> > >>>>
> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInter
> > >>>>ceptor.handleMessage(SAAJOutInterceptor.java:158) at
> > >>>>
> > >>>>
> > >>>>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
> > >>>>rChain.java:236) at
> > >>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483) at
> > >>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309) at
> > >>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261) at
> > >>>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> at
> > >>>>
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124
> > >>>>) ... 30 more
> > >>>> Caused by: java.io.IOException: Invalid white space character (0x1)
> in
> > >>>> text
> > >>>> to output
> > >>>> at com.ctc.wstx.sw.XmlWriter.throwInvalidChar(XmlWriter.java:545)
> > >>>> at
> > >>>>
> > >>>>
> > >>>>
> com.ctc.wstx.sw.BufferingXmlWriter.writeCharacters(BufferingXmlWriter.
> > >>>>java:531) at
> > >>>>
> > >>>>
> > >>>>
> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java
> > >>>>:509) ... 40 more
> > >>>>
> > >>>>
> > >>>> Requests work fine though if I don't use WSS4JOutInterceptor.
> > >>>> Problematic
> > >>>> chars get escaped as &#XX.
> > >>>>
> > >>>> I tried that with both CXF 2.2.0-fuse and 2.2.5.
> > >>>> Is there some sort of configuration required to avoid that issue?
> > >>>>
> > >>>>
> > >>>> Thanks,
> > >>>> Pavel
> > >>
> > >> --
> > >> Best regards,
> > >> Pavel
> >
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
--
Best regards,
Pavel
Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in text to output"
Posted by Daniel Kulp <dk...@apache.org>.
On Mon December 7 2009 9:27:36 am Pavel wrote:
> Ok, I'm a bit lost then, so I'll just state once again what I observed
> before and read in your responses.
>
> A. Input
> 1. There are whitespace characters with code <0x20, that may come in bean
> string properties, that are used.
> 2. By default CXF handles them by quoting into output stream. &#XX. Client
> able to send out the request
This is technically a bug in JAXB, it shouldn't be doing that. It SHOULD be
throwing an exception, but not something I would normally worry about.
> 3. With WSS4JOutInterceptor enabled CXF behaivour changes, exception is
> thrown (stacktrace available in previous posts)
Actually, it would also change with Aegis or XMLBeans. For JAXB, we
normally use an optimization to bypass the XMLStreamWriter which is much
faster, but allows JAXB to encode this case in an invalid way. If we turn
off the optimization (there is a flag for that) and go through the
XMLStreamWriter, it would throw the same exception. Again, bug in JAXB.
> B. Comments
> 1. XML 1.0 prohibits these characters.
> 2. CXF cannot marshall u+0001 in a string. (Although it does in A2).
> 3. It is up to the app to fix the content somehow.
> 4. if you have to ship chars like this, you need to push them around as
> bytes.
>
> C. My additional observations.
> 1. The validation itself comes from the woodstox used by
> SAAJOutInterceptor.
> 2. It is WSS4JOutInterceptor that adds
> SAAJOutInterceptor into the interceptor chain.
There are other use cases as well. Example: having a JAXWS SOAPHandler on
the chain would also trigger adding it.
> 3. http://jira.codehaus.org/browse/WSTX-223 asks for the ability to turn
> that validation off, but this issue is "open"/not implemented.
> 4. Woodstox 4 has an option to replace illegal characters with e.g. spaces;
> see http://www.cowtowncoder.com/blog/archives/2008/12/entry_106.html
> 5. CXF uses Woodstox 3.x.x
>
> Are there any plans for CXF to update to Woodstox 4.x?
CXF trunk (targetting 2.3) is using woodstox 4. The branches SHOULD work
fine with 4 as well if you want to use 4 instead of 3.x.
> And then expose
> option to replace/handle these whitespace characters?
>
> Or otherwise, could you recommend a way to plug into request/response
> processing and replace these chars via CXF API?
Well, one option is to write a XMLStreamWriter wrapper that forwards all the
calls to a the original writer except for the writeCharacter methods (and
probably writeAttribute). Those methods would escape or replace any invalid
content and then call the original. An interceptor running immediately after
the StaxOutInterceptor would take the original XMLStreamWriter and wrapper it
with yours and replace it.
You could also configure in your own XMLOutputFactory that does it as well
that wouldn't require an interceptor, but you would need to override/wrapper
more methods there as well.
Dan
>
> Thanks,
> Pavel
>
> On Mon, Dec 7, 2009 at 3:19 PM, Benson Margulies
<bi...@gmail.com>wrote:
> > cxf cannot marshall u+0001 in a string. the best it could do is throw
> > sooner. it is up to the app. it is a strange feature of jax-whatever that
> > string values are constrained to XML 1.0 valid chars, but there you are.
> > if you have to ship chars like this, you need to push them around as
> > bytes.
> >
> >
> > On Dec 7, 2009, at 7:08 AM, Pavel <pa...@gmail.com> wrote:
> >
> > But that's not me, it is CXF that produces XML representation of that
> >
> >> character. I expect CXF to take care of marshalling specifics, including
> >> proper escaping of special characters.
> >>
> >> Moreover, as I mentioned, CXF does that work well unless/until security
> >> interceptor comes into play.
> >>
> >> So obviously there is an XML representation for the data I want to send,
> >> and
> >> I'm back to may question - what is/whether there is a way to make
> >> security interceptor handle 0x1 properly?
> >>
> >> Thanks,
> >> Pavel
> >>
> >> On Mon, Dec 7, 2009 at 1:18 PM, Benson Margulies <bimargulies@gmail.com
> >>
> >> >wrote:
> >>
> >> XML prohibits that character. you cannot sent it in an xsd:string.
> >>
> >>> On Dec 7, 2009, at 6:10 AM, Pavel <pa...@gmail.com> wrote:
> >>>
> >>> Hello,
> >>>
> >>>> I'm facing an issue with CXF + WSS4JOutInterceptor.
> >>>> Seems like it is unable to hadle strings that contain characters with
> >>>> hex
> >>>> code <0x20; Client fails to send request with the following stacktrace
> >>>>
> >>>> javax.xml.ws.soap.SOAPFaultException: Problem writing SAAJ model to
> >>>> stream
> >>>> at
> >>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146
> >>>>) *at $Proxy125.isStayQualified(Unknown Source)* << that is my client
> >>>> ...
> >>>> Caused by: com.ctc.wstx.exc.WstxIOException: *Invalid white space
> >>>> character
> >>>> (0x1) in text to output*
> >>>> at
> >>>>
> >>>>
> >>>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java
> >>>>:511) at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:434) at
> >>>> org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:412) at
> >>>>
> >>>>
> >>>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInter
> >>>>ceptor.handleMessage(SAAJOutInterceptor.java:197) at
> >>>>
> >>>>
> >>>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInter
> >>>>ceptor.handleMessage(SAAJOutInterceptor.java:158) at
> >>>>
> >>>>
> >>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
> >>>>rChain.java:236) at
> >>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483) at
> >>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309) at
> >>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261) at
> >>>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at
> >>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124
> >>>>) ... 30 more
> >>>> Caused by: java.io.IOException: Invalid white space character (0x1) in
> >>>> text
> >>>> to output
> >>>> at com.ctc.wstx.sw.XmlWriter.throwInvalidChar(XmlWriter.java:545)
> >>>> at
> >>>>
> >>>>
> >>>> com.ctc.wstx.sw.BufferingXmlWriter.writeCharacters(BufferingXmlWriter.
> >>>>java:531) at
> >>>>
> >>>>
> >>>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java
> >>>>:509) ... 40 more
> >>>>
> >>>>
> >>>> Requests work fine though if I don't use WSS4JOutInterceptor.
> >>>> Problematic
> >>>> chars get escaped as &#XX.
> >>>>
> >>>> I tried that with both CXF 2.2.0-fuse and 2.2.5.
> >>>> Is there some sort of configuration required to avoid that issue?
> >>>>
> >>>>
> >>>> Thanks,
> >>>> Pavel
> >>
> >> --
> >> Best regards,
> >> Pavel
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in
text to output"
Posted by Pavel <pa...@gmail.com>.
Ok, I'm a bit lost then, so I'll just state once again what I observed
before and read in your responses.
A. Input
1. There are whitespace characters with code <0x20, that may come in bean
string properties, that are used.
2. By default CXF handles them by quoting into output stream. &#XX. Client
able to send out the request
3. With WSS4JOutInterceptor enabled CXF behaivour changes, exception is
thrown (stacktrace available in previous posts)
B. Comments
1. XML 1.0 prohibits these characters.
2. CXF cannot marshall u+0001 in a string. (Although it does in A2).
3. It is up to the app to fix the content somehow.
4. if you have to ship chars like this, you need to push them around as
bytes.
C. My additional observations.
1. The validation itself comes from the woodstox used by SAAJOutInterceptor.
2. It is WSS4JOutInterceptor that adds SAAJOutInterceptor into the
interceptor chain.
3. http://jira.codehaus.org/browse/WSTX-223 asks for the ability to turn
that validation off, but this issue is "open"/not implemented.
4. Woodstox 4 has an option to replace illegal characters with e.g. spaces;
see http://www.cowtowncoder.com/blog/archives/2008/12/entry_106.html
5. CXF uses Woodstox 3.x.x
Are there any plans for CXF to update to Woodstox 4.x? And then expose
option to replace/handle these whitespace characters?
Or otherwise, could you recommend a way to plug into request/response
processing and replace these chars via CXF API?
Thanks,
Pavel
On Mon, Dec 7, 2009 at 3:19 PM, Benson Margulies <bi...@gmail.com>wrote:
> cxf cannot marshall u+0001 in a string. the best it could do is throw
> sooner. it is up to the app. it is a strange feature of jax-whatever that
> string values are constrained to XML 1.0 valid chars, but there you are. if
> you have to ship chars like this, you need to push them around as bytes.
>
>
> On Dec 7, 2009, at 7:08 AM, Pavel <pa...@gmail.com> wrote:
>
> But that's not me, it is CXF that produces XML representation of that
>> character. I expect CXF to take care of marshalling specifics, including
>> proper escaping of special characters.
>>
>> Moreover, as I mentioned, CXF does that work well unless/until security
>> interceptor comes into play.
>>
>> So obviously there is an XML representation for the data I want to send,
>> and
>> I'm back to may question - what is/whether there is a way to make security
>> interceptor handle 0x1 properly?
>>
>> Thanks,
>> Pavel
>>
>> On Mon, Dec 7, 2009 at 1:18 PM, Benson Margulies <bimargulies@gmail.com
>> >wrote:
>>
>> XML prohibits that character. you cannot sent it in an xsd:string.
>>>
>>>
>>> On Dec 7, 2009, at 6:10 AM, Pavel <pa...@gmail.com> wrote:
>>>
>>> Hello,
>>>
>>>>
>>>> I'm facing an issue with CXF + WSS4JOutInterceptor.
>>>> Seems like it is unable to hadle strings that contain characters with
>>>> hex
>>>> code <0x20; Client fails to send request with the following stacktrace
>>>>
>>>> javax.xml.ws.soap.SOAPFaultException: Problem writing SAAJ model to
>>>> stream
>>>> at
>>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146)
>>>> *at $Proxy125.isStayQualified(Unknown Source)* << that is my client
>>>> ...
>>>> Caused by: com.ctc.wstx.exc.WstxIOException: *Invalid white space
>>>> character
>>>> (0x1) in text to output*
>>>> at
>>>>
>>>>
>>>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:511)
>>>> at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:434)
>>>> at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:412)
>>>> at
>>>>
>>>>
>>>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:197)
>>>> at
>>>>
>>>>
>>>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:158)
>>>> at
>>>>
>>>>
>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
>>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483)
>>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309)
>>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261)
>>>> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>>>> at
>>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
>>>> ... 30 more
>>>> Caused by: java.io.IOException: Invalid white space character (0x1) in
>>>> text
>>>> to output
>>>> at com.ctc.wstx.sw.XmlWriter.throwInvalidChar(XmlWriter.java:545)
>>>> at
>>>>
>>>>
>>>> com.ctc.wstx.sw.BufferingXmlWriter.writeCharacters(BufferingXmlWriter.java:531)
>>>> at
>>>>
>>>>
>>>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:509)
>>>> ... 40 more
>>>>
>>>>
>>>> Requests work fine though if I don't use WSS4JOutInterceptor.
>>>> Problematic
>>>> chars get escaped as &#XX.
>>>>
>>>> I tried that with both CXF 2.2.0-fuse and 2.2.5.
>>>> Is there some sort of configuration required to avoid that issue?
>>>>
>>>>
>>>> Thanks,
>>>> Pavel
>>>>
>>>>
>>>
>>
>> --
>> Best regards,
>> Pavel
>>
>
Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in text to output"
Posted by Benson Margulies <bi...@gmail.com>.
cxf cannot marshall u+0001 in a string. the best it could do is throw
sooner. it is up to the app. it is a strange feature of jax-whatever
that string values are constrained to XML 1.0 valid chars, but there
you are. if you have to ship chars like this, you need to push them
around as bytes.
On Dec 7, 2009, at 7:08 AM, Pavel <pa...@gmail.com> wrote:
> But that's not me, it is CXF that produces XML representation of that
> character. I expect CXF to take care of marshalling specifics,
> including
> proper escaping of special characters.
>
> Moreover, as I mentioned, CXF does that work well unless/until
> security
> interceptor comes into play.
>
> So obviously there is an XML representation for the data I want to
> send, and
> I'm back to may question - what is/whether there is a way to make
> security
> interceptor handle 0x1 properly?
>
> Thanks,
> Pavel
>
> On Mon, Dec 7, 2009 at 1:18 PM, Benson Margulies <bimargulies@gmail.com
> >wrote:
>
>> XML prohibits that character. you cannot sent it in an xsd:string.
>>
>>
>> On Dec 7, 2009, at 6:10 AM, Pavel <pa...@gmail.com> wrote:
>>
>> Hello,
>>>
>>> I'm facing an issue with CXF + WSS4JOutInterceptor.
>>> Seems like it is unable to hadle strings that contain characters
>>> with hex
>>> code <0x20; Client fails to send request with the following
>>> stacktrace
>>>
>>> javax.xml.ws.soap.SOAPFaultException: Problem writing SAAJ model
>>> to stream
>>> at
>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
>>> 146)
>>> *at $Proxy125.isStayQualified(Unknown Source)* << that is my
>>> client
>>> ...
>>> Caused by: com.ctc.wstx.exc.WstxIOException: *Invalid white space
>>> character
>>> (0x1) in text to output*
>>> at
>>>
>>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters
>>> (BaseStreamWriter.java:511)
>>> at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:434)
>>> at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:412)
>>> at
>>>
>>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor
>>> $SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:197)
>>> at
>>>
>>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor
>>> $SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:158)
>>> at
>>>
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept
>>> (PhaseInterceptorChain.java:236)
>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483)
>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309)
>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261)
>>> at org.apache.cxf.frontend.ClientProxy.invokeSync
>>> (ClientProxy.java:73)
>>> at
>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:
>>> 124)
>>> ... 30 more
>>> Caused by: java.io.IOException: Invalid white space character
>>> (0x1) in
>>> text
>>> to output
>>> at com.ctc.wstx.sw.XmlWriter.throwInvalidChar(XmlWriter.java:545)
>>> at
>>>
>>> com.ctc.wstx.sw.BufferingXmlWriter.writeCharacters
>>> (BufferingXmlWriter.java:531)
>>> at
>>>
>>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters
>>> (BaseStreamWriter.java:509)
>>> ... 40 more
>>>
>>>
>>> Requests work fine though if I don't use WSS4JOutInterceptor.
>>> Problematic
>>> chars get escaped as &#XX.
>>>
>>> I tried that with both CXF 2.2.0-fuse and 2.2.5.
>>> Is there some sort of configuration required to avoid that issue?
>>>
>>>
>>> Thanks,
>>> Pavel
>>>
>>
>
>
> --
> Best regards,
> Pavel
Re: WSS4JOutInterceptor and "Invalid white space character (0x1) in
text to output"
Posted by Pavel <pa...@gmail.com>.
But that's not me, it is CXF that produces XML representation of that
character. I expect CXF to take care of marshalling specifics, including
proper escaping of special characters.
Moreover, as I mentioned, CXF does that work well unless/until security
interceptor comes into play.
So obviously there is an XML representation for the data I want to send, and
I'm back to may question - what is/whether there is a way to make security
interceptor handle 0x1 properly?
Thanks,
Pavel
On Mon, Dec 7, 2009 at 1:18 PM, Benson Margulies <bi...@gmail.com>wrote:
> XML prohibits that character. you cannot sent it in an xsd:string.
>
>
> On Dec 7, 2009, at 6:10 AM, Pavel <pa...@gmail.com> wrote:
>
> Hello,
>>
>> I'm facing an issue with CXF + WSS4JOutInterceptor.
>> Seems like it is unable to hadle strings that contain characters with hex
>> code <0x20; Client fails to send request with the following stacktrace
>>
>> javax.xml.ws.soap.SOAPFaultException: Problem writing SAAJ model to stream
>> at
>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146)
>> *at $Proxy125.isStayQualified(Unknown Source)* << that is my client
>> ...
>> Caused by: com.ctc.wstx.exc.WstxIOException: *Invalid white space
>> character
>> (0x1) in text to output*
>> at
>>
>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:511)
>> at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:434)
>> at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:412)
>> at
>>
>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:197)
>> at
>>
>> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:158)
>> at
>>
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483)
>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309)
>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261)
>> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>> at
>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
>> ... 30 more
>> Caused by: java.io.IOException: Invalid white space character (0x1) in
>> text
>> to output
>> at com.ctc.wstx.sw.XmlWriter.throwInvalidChar(XmlWriter.java:545)
>> at
>>
>> com.ctc.wstx.sw.BufferingXmlWriter.writeCharacters(BufferingXmlWriter.java:531)
>> at
>>
>> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:509)
>> ... 40 more
>>
>>
>> Requests work fine though if I don't use WSS4JOutInterceptor. Problematic
>> chars get escaped as &#XX.
>>
>> I tried that with both CXF 2.2.0-fuse and 2.2.5.
>> Is there some sort of configuration required to avoid that issue?
>>
>>
>> Thanks,
>> Pavel
>>
>
--
Best regards,
Pavel