Search code examples
web-servicesclientcxfxml-1.1

Configuring CXF web service client to read XML 1.1 responses


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.


Solution

  • It looks like the answer is... there is no way to pre-configure CXF to expect XML 1.1 by default.

    Essentially, if XML comes in without a version tag:

    <?xml version="1.1">
    

    Then it isn't XML 1.1. That's the problem here. If the xml header existed and specified XML 1.1, then the parser in CXF would parse it as XML 1.1. .NET web services don't (by default) send any XML header tag, so the parser in CXF parses it (correctly) as XML 1.0.

    That said, there might be a way to catch the input stream before it gets parsed by CXF, and "insert" an XML version header that specifies 1.1, which would "fix" the problem for me. If I find a way to get it to work, I'll post it.