United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6936624 sharing cached schema causing cvc-complex-type.2.4.b error
JDK-6936624 : sharing cached schema causing cvc-complex-type.2.4.b error

Details
Type:
Bug
Submit Date:
2010-03-19
Status:
Closed
Updated Date:
2012-04-25
Project Name:
JDK
Resolved Date:
2010-03-23
Component:
xml
OS:
generic,solaris_10
Sub-Component:
javax.xml.validation
CPU:
sparc,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6,6u14
Fixed Versions:
1.4.0 (1.4)

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

Description
Hi,

IHAC (Accor Hotels) who seems to be hitting CR 6773084 "javax.xml.validation.Schema is not thread safe" during his message queue migration on Solaris 10 Update 3 on a Sun Fire T2000. He suspects this CR because:

   1. the problem is not reproducible with JDK 5.0 (this is the w/a implemented).
   2. if he uses directly the Xerces version bundled with his application's JAXP version (taken at http://repo2.maven.org/maven2/xml-apis/xml-apis/1.3.04/), the problem goes away too.
   3. the error messages looks like the one in CR 6773084:
      2009-11-02 00:40:27,972 ERROR model.OTAReceiverImpl : erreur de validation de la request com.accor.commons.xmlschemas.SchemaValidationException: SAXException : cvc-complex-type.2.4.b: The content of element 'POS' is not complete. One of '{"http://www.opentravel.org/OTA/2003/05":Source}' is expected.
              at com.accor.commons.xmlschemas.jaxp.JaxpSchemaValidator.validateXmlWithSchema(JaxpSchemaValidator.java:80)
              at com.accor.commons.xmlschemas.jaxp.JaxpSchemaValidator.validateXmlWithSchema(JaxpSchemaValidator.java:47)
              at com.accor.ota.receiver.model.OTAReceiverImpl.validateOTARequest(OTAReceiverImpl.java:434)
              at com.accor.ota.receiver.model.OTAReceiverImpl.getResponse(OTAReceiverImpl.java:545)
              at com.accor.ota.receiver.webappcore.BaseAbstractOTAServlet.doPost(BaseAbstractOTAServlet.java:85)
              at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
              at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
              at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
              at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
              at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
              at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
              at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
              at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
              at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
              at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
              at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
              at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
              at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
              at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
              at java.lang.Thread.run(Thread.java:619)
      Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.b: The content of element 'POS' is not complete. One of '{"http://www.opentravel.org/OTA/2003/05":Source}' is expected.
              at com.accor.commons.xmlschemas.XmlValidationHandler.error(XmlValidationHandler.java:57)
              at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:134)
              at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384)
              at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318)
              at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:410)
              at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3165)
              at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.elementLocallyValidComplexType(XMLSchemaValidator.java:3147)
              at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.elementLocallyValidType(XMLSchemaValidator.java:3076)
              at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.processElementContent(XMLSchemaValidator.java:2978)
   4. the problem is seen only on the production system. 800 XML valid messages are discarded (on 300.000 XML messages) with this error message.

My questions are:

   1. is it possible to escalate CR 6773084 to ask for a fix, knowing that my customer is unlikely to provide us a testcase? And if it turns out to be a Xerces, will the customer has to with JDK 7 to have this newer version integrated?
   2. what is the Xerces version bundled with the JDK 6? Despite my searches, I was unable to find it the documentations or by looking in the code.
   3. customer is wondering if we make some modifications to the Apache Xerces version. For me, I think answer is "no, this is strictly the same version as given by Apache": correct?

Thanks,
Gildas.

                                    

Comments
EVALUATION

Initially, I thought this was the same as 6773084. But after further testing, I found that the fix that worked for the customer did not resolve 6773084. The test for 6773084 still fails from time to time, which indicates there's a race condition. I've therefore created this new change request to resolve the customer issue and I'll get back to 6773084 in a later time. Can you please re-associate the customer escalation to this new change request?
                                     
2010-03-19
EVALUATION

All tests are passed. This fix is now in jaxp 1.4 and integration into jdk6 update 20 has been requested and approved.
                                     
2010-03-23



Hardware and Software, Engineered to Work Together