This week's book giveaway is in the General Computing forum. We're giving away four copies of Arduino in Action and have Martin Evans, Joshua Noble, and Jordan Hochenbaum on-line! See this thread for details.
We have a WSM(Webservice Management Application) product which will generate a 'Proxy WSDL URL' for a 'Real WSDL URL' and it does security/auditing/logging/routing and other stuffs at runtime while getting a webservice request (on Proxy WSDL) and route it to the Functional(Real WSDL URL - Application server where the actual webservice is deployed) endpoint.
On receiving response from the functional endpoint, it again comes back to WSM which has to just give the response back to the user unless and until some special policies are attached (like schema validation policy - it will validate the response body based on the schema XSD)
Here, while reading the response (from functional/application endpoint) over the wire and at the time of creating the actual SoapResponse (XmlResponse) for the end user
xercesImpl.jar is used to parse the data -lsParser.parse(lsInput); which is throwing the exception "org.w3c.dom.ls.LSException: An invalid XML character (Unicode: 0x16) was found in the element content of the document" when it sees not properly formatted XML at any cause (having incompatible data/special character).
As the exception does not even give enough information like where the XML is corrupt/having incompatible data/special character, we cant have a control to do anything from our application/product side ,as it is third party jar xercesImpl.jar. It would be really very helpful if we
> either get a option/boolean to turn off the validation logic which is done internally in xercesImpl.jar at the time of parsing 'lsParser.parse(lsInput);'
> or get additional information in the exception (original cause - like the incompatible/special character (or) a full corrupted response in the exception itself) with which we can get a clue to resolve the issue.
There aren't any parser options to allow you to parse XML documents which are not well-formed.
As for finding the problem, it's unfortunate you aren't getting a SAXParseException (which does include location information). There isn't any useful information to be had from the LSException.
However to resolve the issue you're going to have to look at the code which generates that XML. It should be written so that it generates well-formed XML is the bottom line. And if it's not your code generating that XML then it isn't your problem.