mbeckerle commented on code in PR #1060:
URL: https://github.com/apache/daffodil/pull/1060#discussion_r1272754968


##########
daffodil-lib/src/test/scala/org/apache/daffodil/lib/util/TestXMLCatalogAndValidate.scala:
##########
@@ -446,48 +452,56 @@ class SchemaAwareFactoryAdapter() extends 
NoBindingFactoryAdapter {
   f.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true)
   f.setValidating(true)
   val p = f.newSAXParser()
-  val xr = p.getXMLReader()
+  val r = p.getXMLReader()
+
+  // We must use XMLReader setProperty() function to set the entity 
resolver--calling
+  // setEntityResolver with the Xerces XML reader causes validation to fail 
for some
+  // reason. We call the right function below, but unfortunately, scala-xml 
calls
+  // setEntityResolver in loadDocument(), which cannot be disabled and 
scala-xml does not
+  // want to change. To avoid this, we wrap the Xerces XMLReader in an 
XMLFilterImpl and
+  // override setEntityResolver to a no-op. However, XMLFilterImpl parse() 
calls
+  // setEntityResolver() on the XMLReader, which for the same reason as before 
causes
+  // issues. To fix this, we can override parse() to just pass through to the 
parent, but
+  // that means we must override the various set/get handler functions to also 
pass
+  // through to the parent.

Review Comment:
   This is really jumping through hoops. 
   
   I'm glad we have something that works, but I'd say scala-xml is a mess if it 
requires this.  The legacy of this XSD decision not to specify what 
schemaLocation really does, ... is causing quite a bit of havoc. 
   
   The real comment here is this whole system is mostly duplicate of our 
loader, so we're not testing that loader here. 
   
   I'm all for tests that characterize how a library works, particularly if the 
way it works is flakey and may evolve. But in this case we have almost the same 
piece of code in our library and here. 
   
   Shouldn't we be calling our own library here to be sure it does this right? 
   
   Or are there sufficient test elsewhere of that, and the purpose of this 
really is to illustrate usage for this foolish resolver crud in scala-xml?
   
   



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to