We had some 2.1 based SOAP code that was working fine with Xerces 1.3.0, but stopped
working when we switched to Xerces 1.4.
I captured a SOAP request message and tried to validate it using a simple framework
(xfront) that invoked SAX2Count with schema validation turned on, and validation
failed.
I traced the problem down to a null pointer exception that seemed to relate to the
resolution of Complex types, and cut away the XML from my test message until I had the
most basic XML structure that would cause the problem.
I was left with this:
<?xml version='1.0' encoding='UTF-8'?>
<ns1:placeBuyOrder
xmlns:ns1="urn:Broking"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns="urn:Broking"
xsi:schemaLocation="urn:Broking broking.xsd">
<CustomerSpecifier xsi:type="CustomerSpecifier">
</CustomerSpecifier>
</ns1:placeBuyOrder>
Where Broking is defined in an external xsd file.
When I ran this through my validation test code, I got the exception:
java.lang.NullPointerException
at
org.apache.xerces.validators.common.XMLValidator.validateElementAndAttributes(XMLValidator.java:3300)
at
org.apache.xerces.validators.common.XMLValidator.callStartElement(XMLValidator.java:1155)
at
org.apache.xerces.framework.XMLDocumentScanner.scanElement(XMLDocumentScanner.java:1862)
at
org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1238)
at
org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381)
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1035)
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1076)
at sax.SAXCount.print(SAXCount.java:158)
at sax.SAXCount.main(SAXCount.java:392)
When I removed the 'xsi:type="CustomerSpecifier"' reference from the XML, the XML
validated without a problem. I tried the same fix for another XML message structure,
and noticed that because a namespace was already defined for the section, the xsi:type
wasn't required for the validation to work.
I traced the problem to a line of code in XMLValidator (Xerces1.4.0):
if ((typeInfo.baseComplexTypeInfo.blockSet & derivationMethod)
!= 0) {
...where typeInfo.baseComplexTypeInfo was set to null.
Has anyone else run into this problem? If so, do any workarounds exist? It would seem
that the problem would go away
if the xsi:type references could be turned off from SOAP client messages, but I can't
see a way to do this.
Thanks,
Paul Lanceman
Deutsche Bank
--
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorised copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
