You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "BillJames@Q" <bi...@qualcomm.com> on 2012/03/30 03:56:25 UTC
Configuring CXF to expect XML 1.1
I'm using CXF to generate an interface to a .NET web service client.
However, sometimes when I use the client, I get an error:
WARNING: Interceptor for
{http://xxxxxx.com}ChangeRequestWebService#{http://xxxxxx.com/ChangeRequestWebService}GetChangeRequestById
has thrown exception, unwinding now
[com.ctc.wstx.exc.WstxLazyException]
com.ctc.wstx.exc.WstxParsingException: Illegal character entity: expansion
character (code 0x1b
at [row,col {unknown-source}]: [76,44]
>From many other sources online, it's obvious that this is because the
webservice is encoding its response in XML 1.1, while my CXF client is
reading that response expecting XML 1.0, and the special character 0x1b is
illegal in XML 1.0. Now, I don't want to argue about whether the .NET
service *should* be using XML 1.1 in its response, when the WSDL is
obviously 1.0 (since that's the spec). I just want to be able to read what
they send without errors.
Looking at the dependencies in the CXF client, they use WoodStox 4.1.1 which
(from their site) clearly supports XML 1.1. **What I want to know is, is
there any way to configure my CXF client (via binding at wsdl2java time, or
during run-time) to use an XML 1.1 parser when receiving responses?** All I
can find is people saying that they shouldn't be using 1.1, or having the
server-side filter these characters. Note that I can't filter the
characters client-side, as I have to send the data back to the server, and
validation would fail.
As an alternative, I suppose the .NET service could in some fashion SPECIFY
that they're using XML 1.1 in their response, but I don't control that
service, so it would be more troublesome to figure out their problem for
them and then suggest they fix it. Plus, the data they're sending is in a
DB, so it's not the web service's fault that it has XML 1.1-only characters
in it.
--
View this message in context: http://cxf.547215.n5.nabble.com/Configuring-CXF-to-expect-XML-1-1-tp5605504p5605504.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Configuring CXF to expect XML 1.1
Posted by Daniel Kulp <dk...@apache.org>.
On Friday, March 30, 2012 07:42:18 AM BillJames@Q wrote:
> Yes, thanks. We've determined that they are NOT sending that version info
> with their response, and that the parser is working correctly.
> Unfortunately, this doesn't solve the problem. I guess it's helpful to
> know that if the version declaration WAS put in the response, then the
> parser would parse it using XML 1.1?
>
> I was originally asking if there was a way to get the CXF client to
> /expect/ XML 1.1 (essentially making it the default), as I know that's
> what's being sent.
I don't see an "easy" way. You would likely need to stick an interceptor
in the chain that runs before the stax in interceptor that would take the
InputStream and wrap it with a new stream that would either filter the 1.0
prologue into a 1.1 version or, if there isn't a prologue there, fake one
that states 1.1.
Dan
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Configuring-CXF-to-expect-XML-1-1-tp56055
> 04p5606861.html Sent from the cxf-user mailing list archive at Nabble.com.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Configuring CXF to expect XML 1.1
Posted by "BillJames@Q" <bi...@qualcomm.com>.
Yes, thanks. We've determined that they are NOT sending that version info
with their response, and that the parser is working correctly.
Unfortunately, this doesn't solve the problem. I guess it's helpful to know
that if the version declaration WAS put in the response, then the parser
would parse it using XML 1.1?
I was originally asking if there was a way to get the CXF client to /expect/
XML 1.1 (essentially making it the default), as I know that's what's being
sent.
--
View this message in context: http://cxf.547215.n5.nabble.com/Configuring-CXF-to-expect-XML-1-1-tp5605504p5606861.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Configuring CXF to expect XML 1.1
Posted by Daniel Kulp <dk...@apache.org>.
Can you capture the payload of the message? Is there a processing
instruction at the start that marks it as XML 1.1?
<?xml version="1.1"...>
If not, it's a 1.0 document, not 1.1 and woodstox is correct in rejecting
it.
Dan
On Thursday, March 29, 2012 06:56:25 PM BillJames@Q wrote:
> I'm using CXF to generate an interface to a .NET web service client.
> However, sometimes when I use the client, I get an error:
>
> WARNING: Interceptor for
> {http://xxxxxx.com}ChangeRequestWebService#{http://xxxxxx.com/ChangeReques
> tWebService}GetChangeRequestById has thrown exception, unwinding now
> [com.ctc.wstx.exc.WstxLazyException]
> com.ctc.wstx.exc.WstxParsingException: Illegal character entity: expansion
> character (code 0x1b
> at [row,col {unknown-source}]: [76,44]
>
> From many other sources online, it's obvious that this is because the
> webservice is encoding its response in XML 1.1, while my CXF client is
> reading that response expecting XML 1.0, and the special character 0x1b is
> illegal in XML 1.0. Now, I don't want to argue about whether the .NET
> service *should* be using XML 1.1 in its response, when the WSDL is
> obviously 1.0 (since that's the spec). I just want to be able to read
> what they send without errors.
>
> Looking at the dependencies in the CXF client, they use WoodStox 4.1.1
> which (from their site) clearly supports XML 1.1. **What I want to know
> is, is there any way to configure my CXF client (via binding at wsdl2java
> time, or during run-time) to use an XML 1.1 parser when receiving
> responses?** All I can find is people saying that they shouldn't be
> using 1.1, or having the server-side filter these characters. Note that
> I can't filter the characters client-side, as I have to send the data
> back to the server, and validation would fail.
>
> As an alternative, I suppose the .NET service could in some fashion
> SPECIFY that they're using XML 1.1 in their response, but I don't control
> that service, so it would be more troublesome to figure out their problem
> for them and then suggest they fix it. Plus, the data they're sending is
> in a DB, so it's not the web service's fault that it has XML 1.1-only
> characters in it.
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Configuring-CXF-to-expect-XML-1-1-tp56055
> 04p5605504.html Sent from the cxf-user mailing list archive at Nabble.com.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Configuring CXF to expect XML 1.1
Posted by Sergey Beryozkin <sb...@gmail.com>.
I feel it should be submitted as an enhancement request to Woodstox,
according to http://www.w3.org/TR/xml11/#sec-xml11,
"XML 1.0 processors must continue to reject documents that contain new
characters in XML names, new line-end conventions, and references to
control characters."
which I guess they do with XML 1.0 too, thus version='1.1' in the
processing instruction should not block them from processing the XML 1.0
compatible payloads
Sergey
On 30/03/12 02:56, BillJames@Q wrote:
> I'm using CXF to generate an interface to a .NET web service client.
> However, sometimes when I use the client, I get an error:
>
> WARNING: Interceptor for
> {http://xxxxxx.com}ChangeRequestWebService#{http://xxxxxx.com/ChangeRequestWebService}GetChangeRequestById
> has thrown exception, unwinding now
> [com.ctc.wstx.exc.WstxLazyException]
> com.ctc.wstx.exc.WstxParsingException: Illegal character entity: expansion
> character (code 0x1b
> at [row,col {unknown-source}]: [76,44]
>
> From many other sources online, it's obvious that this is because the
> webservice is encoding its response in XML 1.1, while my CXF client is
> reading that response expecting XML 1.0, and the special character 0x1b is
> illegal in XML 1.0. Now, I don't want to argue about whether the .NET
> service *should* be using XML 1.1 in its response, when the WSDL is
> obviously 1.0 (since that's the spec). I just want to be able to read what
> they send without errors.
>
> Looking at the dependencies in the CXF client, they use WoodStox 4.1.1 which
> (from their site) clearly supports XML 1.1. **What I want to know is, is
> there any way to configure my CXF client (via binding at wsdl2java time, or
> during run-time) to use an XML 1.1 parser when receiving responses?** All I
> can find is people saying that they shouldn't be using 1.1, or having the
> server-side filter these characters. Note that I can't filter the
> characters client-side, as I have to send the data back to the server, and
> validation would fail.
>
> As an alternative, I suppose the .NET service could in some fashion SPECIFY
> that they're using XML 1.1 in their response, but I don't control that
> service, so it would be more troublesome to figure out their problem for
> them and then suggest they fix it. Plus, the data they're sending is in a
> DB, so it's not the web service's fault that it has XML 1.1-only characters
> in it.
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Configuring-CXF-to-expect-XML-1-1-tp5605504p5605504.html
> Sent from the cxf-user mailing list archive at Nabble.com.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Configuring CXF to expect XML 1.1
Posted by Benson Margulies <bi...@gmail.com>.
On Thu, Mar 29, 2012 at 9:56 PM, BillJames@Q <bi...@qualcomm.com> wrote:
> I'm using CXF to generate an interface to a .NET web service client.
> However, sometimes when I use the client, I get an error:
>
Is there any W3 standard that covers the use of XML 1.1 in a web service?
>
> WARNING: Interceptor for
> {http://xxxxxx.com}ChangeRequestWebService#{
> http://xxxxxx.com/ChangeRequestWebService}GetChangeRequestById
> has thrown exception, unwinding now
> [com.ctc.wstx.exc.WstxLazyException]
> com.ctc.wstx.exc.WstxParsingException: Illegal character entity: expansion
> character (code 0x1b
> at [row,col {unknown-source}]: [76,44]
>
> From many other sources online, it's obvious that this is because the
> webservice is encoding its response in XML 1.1, while my CXF client is
> reading that response expecting XML 1.0, and the special character 0x1b is
> illegal in XML 1.0. Now, I don't want to argue about whether the .NET
> service *should* be using XML 1.1 in its response, when the WSDL is
> obviously 1.0 (since that's the spec). I just want to be able to read what
> they send without errors.
>
> Looking at the dependencies in the CXF client, they use WoodStox 4.1.1
> which
> (from their site) clearly supports XML 1.1. **What I want to know is, is
> there any way to configure my CXF client (via binding at wsdl2java time, or
> during run-time) to use an XML 1.1 parser when receiving responses?** All
> I
> can find is people saying that they shouldn't be using 1.1, or having the
> server-side filter these characters. Note that I can't filter the
> characters client-side, as I have to send the data back to the server, and
> validation would fail.
>
> As an alternative, I suppose the .NET service could in some fashion SPECIFY
> that they're using XML 1.1 in their response, but I don't control that
> service, so it would be more troublesome to figure out their problem for
> them and then suggest they fix it. Plus, the data they're sending is in a
> DB, so it's not the web service's fault that it has XML 1.1-only characters
> in it.
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Configuring-CXF-to-expect-XML-1-1-tp5605504p5605504.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>