Project

Profile

Help

Support #4282

Failed to process license at C:\\...\\...\\...\\...\\App_Data\\licenses\\saxon-license.lic

Added by Kevon Hayes about 1 month ago. Updated 20 days ago.

Status:
Closed
Priority:
High
Assignee:
Category:
.NET API
Sprint/Milestone:
Start date:
2019-08-14
Due date:
% Done:

0%

Legacy ID:
Applies to branch:
9.9
Fix Committed on Branch:
Fixed in Maintenance Release:

Description

Upon initializing a Processor with my config I get the following exception:

{"Failed to process license at C:\...\...\...\...\App_Data\licenses\saxon-license.lic"}

var saxonConfigPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "App_Data\\licenses\\COMPLY365-SAXON.config");
var saxonConfigFile = new FileStream(saxonConfigPath, FileMode.Open, FileAccess.Write, FileShare.ReadWrite);

// Initialize Saxon Processor with config
_processor = new Processor(saxonConfigFile, new Uri(saxonConfigPath));

// My Config file look like this:

<configuration xmlns="http://saxon.sf.net/ns/configuration"
               edition="PE"
               licenseFileLocation="C:\...\...\...\...\App_Data\licenses\saxon-license.lic"
               label="Comply365.Saxon.Configuration.v0.0.1">
</configuration>

History

#1 Updated by Michael Kay about 1 month ago

  • Description updated (diff)

#2 Updated by Michael Kay about 1 month ago

  • Tracker changed from Bug to Support
  • Assignee set to Michael Kay

licenseFileLocation is a URI, not a filename. It can be an absolute URI, or a URI reference relative to the base URI of the configuration file itself.

URIs never start with "C:", and they never contain backslashes.

Try

licenseFileLocation="file:///C:/.../..../.../.../App_Data/licenses/saxon-license.lic"

#3 Updated by Michael Kay about 1 month ago

  • Status changed from New to In Progress

#4 Updated by Kevon Hayes about 1 month ago

Testing now.

#5 Updated by Kevon Hayes about 1 month ago

That worked in the config file, however I will eventually need the licenseFileLocation to be set programmatically.

Also, the following exception was thrown again downstream: "URI has an authority component" when reaching the line below:

var transformer = _xsltCompiler.Compile(new Uri(stylesheetPath)).Load();

The stylesheetpath uri has been working for months while on SaxonHE, now that we've upgraded to SaxonPE these issues have surfaced. So I don't think the issue is the stylesheet URI as much as it is on the following XSLT calls (but I'm no expert): e.g. file:base-dir, file:parent, and file:list see snippet below.

<xsl:function name="pn:find-image-filepath">
        <xsl:param name="filename"/>

        <xsl:variable name="file-path"
                      select="file:list(file:parent(file:base-dir()), true(), concat($filename, '*'))[1]"/>

        <xsl:choose>
            <xsl:when test="$file-path">
              <xsl:value-of select="file:path-to-uri(concat(file:parent(file:base-dir()), $file-path)))"/>
            </xsl:when>
            <xsl:otherwise>
                <xsl:message terminate="no">Could not find image file "<xsl:value-of select="$filename"/>"
                </xsl:message>
            </xsl:otherwise>
        </xsl:choose>
    </xsl:function>

Is there a way I can set a setting to tell Saxon to ignore particular parsing issues? e.g warnings vs. fatal errors

#6 Updated by Michael Kay about 1 month ago

The issue is going to surface if the stylesheet does anything that makes use of the static base URI, and there are quite a few things that can make use of the static base URI; this is just one example. It would be hard to change all those places to tolerate an invalid URI. For example, relative URIs appearing in xsl:include,xsl:import, or calls on doc() and document() would fail in similar ways.

I'm thinking that since new Uri() doesn't guarantee that the value is a usable URI, we should put some extra validation in at the point of the Compile call to make sure that it's usable, and try and reject it with a decent error message if not.

Note: I think we're now discussing the same issue as in bug #4280, so I suggest we close this one to avoid confusion.

#7 Updated by Kevon Hayes 27 days ago

Michael,

I'm not sure how to close this ticket.

#8 Updated by Michael Kay 20 days ago

  • Status changed from In Progress to Closed

I'm closing this as resolved.

(a) specifying a license file location in the configuration file: this should work provided that the value of the location is an absolute URI, or a relative URI (relative to the location of the configuration file).

(b) the other problems raised in the thread seem to be a duplicate of bug #4280.

General note for all readers: although it is technically possible to retrieve a license file from a remote machine using URIs such as HTTP URIs or file URIs representing UNC paths, this does not remove the legal and contractual obligation to purchase one license unit for each machine on which the software is actually executed. This is true even if that is a machine with no filestore of its own.

#9 Updated by Kevon Hayes 20 days ago

Michael,

Licensing should NOT be an issue for us as we purchased a redistributable license.

Please register to edit this issue

Also available in: Atom PDF