Project

Profile

Help

Feature #6240

closed

Include custom error feedback when using .NET XmlResolver

Added by Emanuel Wlaschitz 12 months ago. Updated 6 months ago.

Status:
Closed
Priority:
Low
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
2023-11-06
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
10
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:
.NET

Description

This is a follow-up to #6214 to get better error feedback to our end-users.

Using a simplified XmlResolver:

    sealed class CustomResolver : XmlResolver
    {
        private readonly XmlResolver _innerResolver;
        public CustomResolver(XmlResolver innerResolver) => _innerResolver = innerResolver;
        public override ICredentials Credentials { set { _innerResolver.Credentials = value; } }
        public override Uri ResolveUri(Uri baseUri, string relativeUri) => base.ResolveUri(baseUri, relativeUri);

        public override object GetEntity(Uri absoluteUri, string role, Type ofObjectToReturn)
        {
            throw new Exception($"The custom url {absoluteUri} is not available. Use doc-available() to test for this before using document()");
        }
    }

...and a minimal transformation:

var xsltTransformer = CompileTestStylesheet();
xsltTransformer.InputXmlResolver = new CustomResolver(xsltTransformer.InputXmlResolver);
try
{
    var output = new XDocument();
    using (var outputWriter = output.CreateWriter())
    {
        var destination = new TextWriterDestination(outputWriter) { CloseAfterUse = true };
        xsltTransformer.Run(destination);
    }
    Console.WriteLine(output);
}
catch (DynamicError ex)
{
    Console.WriteLine("DYNAMIC ERROR");
    Console.WriteLine(ex);
}

...which is basically:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="3.0">
	<xsl:template match="/">
		<root>
			<xsl:sequence select="document('custom-scheme://test')"/>
		</root>
	</xsl:template>
</xsl:stylesheet>

...yields the following console output:

Error at char 9 in expression in xsl:sequence/@select on line 4 column 61 of xslt-custom-uri-scheme-test1.xsl:
  FODC0002  Exception thrown by URIResolver resolving `custom-scheme://test` against
  `file:///D:/_dev/Saxon10CustomResolverTest1/bin/Debug/xslt-custom-uri-scheme-test1.xsl'.
  Caused by net.sf.saxon.trans.XPathException: The custom url custom-scheme://test/ is not
  available. Use doc-available() to test for this before using document(). Caused by
  cli.System.Exception: The custom url custom-scheme://test/ is not available. Use
  doc-available() to test for this before using document()
  In template rule with match="/" on line 2 of xslt-custom-uri-scheme-test1.xsl
DYNAMIC ERROR
Exception thrown by URIResolver resolving `custom-scheme://test` against `file:///D:/_dev/Saxon10CustomResolverTest1/bin/Debug/xslt-custom-uri-scheme-test1.xsl'

The top part is from the internal console writer thats attached by default (...where I'm wondering: Can we redirect this? It sometimes contains additional information that isn't part of a thrown StaticError, DynamicError and isn't passed into the set ErrorList but would be useful to either the end user themselves or at least us as developers) while the bottom part is from catching the DynamicError.

Note that the top part includes the custom exception message, but the bottom part doesn't.

It would be nice if the thrown DynamicError could include the actual exception message somewhere (preferably as InnerException in .NET; not sure if Java would want to use the same approach.) Right now there is no way of getting this info through normal means; the only workaround we could identify was to pass something (like the IMessageListener2 we attach anyways) into the CustomResolver and directly call methods on it.

I could only test this against Saxon 10, since there are no HE versions of 11/12 yet (nor do I have a license for it at this point.)

Actions #1

Updated by Michael Kay 6 months ago

  • Status changed from New to Closed

I'm going to close this because the whole design for URI resolution has changed completely in later versions of SaxonCS. If there's still a problem, then I think we need to look at it from first principles. But hopefully the new design addresses these concerns.

In particular, we have moved away from the very poorly specified Microsoft XmlResolver interface to our own interface which gives us much more flexibility.

Please register to edit this issue

Also available in: Atom PDF