[
https://issues.apache.org/jira/browse/XERCESJ-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17677606#comment-17677606
]
Radu Coravu edited comment on XERCESJ-1754 at 1/17/23 5:32 AM:
---------------------------------------------------------------
Hi Mukul, thanks, I agree with your analysis. I think one reason we reuse the
parser is for parsing the XML schema references only once as they will remain
as information inside the parser. We could have probably used a grammar pool
instead.
We have a patched version of Xerces on our side and I commented out this entire
code in the XMLSchemaValidator
{code}// boolean parser_settings;
// try {
// parser_settings = componentManager.getFeature(PARSER_SETTINGS);
// }
// catch (XMLConfigurationException e){
// parser_settings = true;
// }
//
// if (!parser_settings) {
// // parser settings have not been changed
// fValidationManager.addValidationState(fValidationState);
// // the node limit on the SecurityManager may have changed so need
to refresh.
// nodeFactory.reset();
// // Re-parse external schema location properties.
// XMLSchemaLoader.processExternalHints(
// fExternalSchemas,
// fExternalNoNamespaceSchema,
// fLocationPairs,
// fXSIErrorReporter.fErrorReporter);
// return;
// }{code}
was (Author: radu_coravu):
Hi Mukul, I agree with your analysis. I think one reason we reuse the parser is
for parsing the XML schema references only once as they will remain as
information inside the parser. We could have probably used a grammar pool
instead.
We have a patched version of Xerces on our side and I commented out this entire
code in the XMLSchemaValidator
{code}// boolean parser_settings;
// try {
// parser_settings = componentManager.getFeature(PARSER_SETTINGS);
// }
// catch (XMLConfigurationException e){
// parser_settings = true;
// }
//
// if (!parser_settings) {
// // parser settings have not been changed
// fValidationManager.addValidationState(fValidationState);
// // the node limit on the SecurityManager may have changed so need
to refresh.
// nodeFactory.reset();
// // Re-parse external schema location properties.
// XMLSchemaLoader.processExternalHints(
// fExternalSchemas,
// fExternalNoNamespaceSchema,
// fLocationPairs,
// fXSIErrorReporter.fErrorReporter);
// return;
// }{code}
> XMLSchemaValidator reset no longer resets id validation caches
> --------------------------------------------------------------
>
> Key: XERCESJ-1754
> URL: https://issues.apache.org/jira/browse/XERCESJ-1754
> Project: Xerces2-J
> Issue Type: Bug
> Components: XML Schema 1.1 Structures
> Reporter: Radu Coravu
> Priority: Major
> Attachments: test.xml, test.xsd
>
>
> I validate an XML with an XML Schema 1.1 file.
> On the first validation the XML is reported valid.
> On the second validation I re-use the parser, the ID values inside elements
> are reported as duplicate and I get errors like this reported:
> {code}Message: cvc-type.3.1.3: The value 'thing122' of element 'uid' is not
> valid.{code}
> Looking at the method
> org.apache.xerces.impl.xs.XMLSchemaValidator.reset(XMLComponentManager),
> there is a fast return inside it:
> {code} if (!parser_settings) {
> // parser settings have not been changed
> fValidationManager.addValidationState(fValidationState);
> // the node limit on the SecurityManager may have changed so need
> to refresh.
> nodeFactory.reset();
> // Re-parse external schema location properties.
> XMLSchemaLoader.processExternalHints(
> fExternalSchemas,
> fExternalNoNamespaceSchema,
> fLocationPairs,
> fXSIErrorReporter.fErrorReporter);
> return;
> }{code}
> and this means all the code which for example cleared the IDs cache:
> {code} // reset ID Context
> if (fIDContext != null) {
> fIDContext.clear();
> }{code}
> is no longer executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
