[GitHub] [daffodil] stevedlawrence commented on a change in pull request #744: SDE if include/import schemaLocation not found.

[GitBox <gi...@apache.org>]

stevedlawrence commented on a change in pull request #744:
URL: https://github.com/apache/daffodil/pull/744#discussion_r797563695



##########
File path: daffodil-lib/src/main/scala/org/apache/daffodil/xml/DaffodilXMLLoader.scala
##########
@@ -215,18 +215,37 @@ class DFDLCatalogResolver private ()
 
     val result = (resolvedId, systemId) match {
       case (null, null) => {
-        // This happens now in some unit tests.
-        // Assert.invariantFailed("resolvedId and systemId were null.")
-        Logger.log.debug(s"Unable to resolve.")
+        // This happens in numerous unit tests.
+        //
+        // It seems that in some situations the resolver is called
+        // to attempt to resolve things certain ways. Such as
+        // providing just the namespace URI, without the systemId.
+        //
+        // So the inability to resolve, in this case anyway, is not an error.
+        //
         None
       }
       case (null, sysId) =>
         {
+          // We did not get a catalog resolution of the nsURI, nor
+          // a straight file resolution of the systemId, so we
+          // use the systemId (which comes from the schemaLocation attribute)
+          // and the classpath.
           val baseURI = if (baseURIString == null) None else Some(new URI(baseURIString))
           val optURI = Misc.getResourceRelativeOption(sysId, baseURI)
           optURI match {
             case Some(uri) => Logger.log.debug(s"Found on classpath: ${uri}.")
-            case None => Logger.log.info(s"Unable to resolve ${sysId} in ${baseURI}")
+            case None => {
+              //
+              // We have to explicitly throw this, because returning with
+              // a no-resolve does not cause Xerces to report an error.
+              // Instead you just get later errors about symbols that can't
+              // be resolved, but it never mentions that an include/import didn't
+              // work.
+              val e = new SAXParseException(
+                s"""DaffodilXMLLoader: Unable to resolve schemaLocation='$systemId'.""", null)
+              throw e

Review comment:
       Is this a bug in Xerces where it doesn't consider faling to resolve `schemaLocation` an error? Or maybe there's some configuration we aren't setting correctly to causes this to be an errors? Seems odd that a failure to resolve this specific thing isn't considered an error when all other failures are handled by Xerces correctly.
   
   Also, I wonder if PR #745, which switches a different xml resolver, would have any affect on this?




-- 
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: commits-unsubscribe@daffodil.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org