Support #4282
closed
Failed to process license at C:\\...\\...\\...\\...\\App_Data\\licenses\\saxon-license.lic
0%
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>
Updated by Michael Kay over 5 years 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"
Updated by Kevon Hayes over 5 years 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
Updated by Michael Kay over 5 years 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.
Updated by Kevon Hayes over 5 years ago
Michael,
I'm not sure how to close this ticket.
Updated by Michael Kay about 5 years 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.
Updated by Kevon Hayes about 5 years ago
Michael,
Licensing should NOT be an issue for us as we purchased a redistributable license.
Please register to edit this issue
.