Project

Profile

Help

Bug #4532

Compiling package to SEF fails when the package (a) uses keys, and (b) was itself loaded from a SEF file

Added by Jeremy Cronk 3 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
XSLT 3.0 packages
Sprint/Milestone:
-
Start date:
2020-04-28
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
10, 9.9
Fix Committed on Branch:
10, 9.9
Fixed in Maintenance Release:

Description

I have an XSLT package which depends on another XSLT package with external assets (an XML file and a JSON file). The package with external assets compiles with no problems, and if I try to run my XSpec tests on the SEF file for this package, they run with no errors (this was done by creating a test stylesheet that used the package and then made its functions public in xsl:accept).

However, when I try to compile a the package depending on this one, I get a confusing error. I'm attaching a mock-up that illustrates the issue.

I'm running saxon9ee.jar with the config set, relocate on, nogo, and an export path to formatters.sef. This is roughly the same command that successfully compiled everything else I've tried to date.

I get this stack trace:

java.lang.UnsupportedOperationException
       at net.sf.saxon.trans.KeyDefinition.export(KeyDefinition.java:353)
       at net.sf.saxon.expr.Component.export(Component.java:229)
       at com.saxonica.ee.trans.StylesheetPackageEE.export(StylesheetPackageEE.java:160)
       at com.saxonica.ee.trans.StylesheetPackageEE.export(StylesheetPackageEE.java:151)
       at com.saxonica.ee.trans.StylesheetPackageEE.export(StylesheetPackageEE.java:92)
       at net.sf.saxon.s9api.XsltExecutable.export(XsltExecutable.java:156)
       at net.sf.saxon.s9api.XsltExecutable.export(XsltExecutable.java:133)
       at net.sf.saxon.Transform.doTransform(Transform.java:776)
       at net.sf.saxon.Transform.main(Transform.java:80)

I asked about this on the mailing list, and Michael Kay told me to try adding -opt:-k to disable a key optimization and see if that worked, but when I tried it I received the same error.

pkg-with-ext-assets.zip (160 KB) pkg-with-ext-assets.zip files to reproduce Jeremy Cronk, 2020-04-28 22:41
string.xsl (8.81 KB) string.xsl Source of string.sef Jeremy Cronk, 2020-05-08 18:46
al3-dictionary.xsl (3.91 KB) al3-dictionary.xsl Source of al3-dictionary.sef Jeremy Cronk, 2020-05-08 18:47
al3-meta-info.xsl (5.33 KB) al3-meta-info.xsl Additional source of al3-dictionary.sef Jeremy Cronk, 2020-05-08 18:47
map.xsl (3.42 KB) map.xsl Dependency of al3-dictionary Jeremy Cronk, 2020-05-08 18:47
array.xsl (1.22 KB) array.xsl Dependency of al3-dictionary Jeremy Cronk, 2020-05-08 18:47

History

#1 Updated by Michael Kay 3 months ago

Sorry about the delay in responding to this. I've been trying to reproduce it, and hitting various unrelated problems, so I'm making progress but not quite at the stage where I can investigate the issue as reported.

It would help to have a clearer idea of the exact sequence of steps you took to reproduce the failure (e.g. what mechanism you used to locate the used packages). It would also help to have the XSLT source for all the packages - with only SEF files produced under 9.9, I can't reproduce and test the bug under 10.0, or try alternative build strategies.

I can see from the SEF file that my original guess, namely that this related to system-generated key definitions, was probably wrong.

#2 Updated by Michael Kay 3 months ago

  • Category set to XSLT 3.0 packages
  • Assignee set to Michael Kay
  • Priority changed from Low to Normal

I have now reproduced the problem. However, it's difficult to diagnose without having the XSLT source code of the library package.

#3 Updated by Michael Kay 3 months ago

It seems that when we export a top-level package containing key definitions, those key definitions are not included in the package's component index, so StylesheetPackageEE.export() does not export them when it iterates over the component index; instead they are exported by a separate call on keyManager.exportKeys().

But when we load a stylesheet from a SEF file, the key definitions are included in the component index, so re-exporting the package attempts to export the keys using the general component export logic, and this crashes.

We don't actually need multiple packages to demonstrate this: to reproduce it, (a) export a stylesheet containing key definitions to a SEF file; (b) load that SEF file and re-export it.

#4 Updated by Michael Kay 3 months ago

  • Subject changed from Compiling package to SEF fails when package uses a package containing external assets to Compiling package to SEF fails when the package (a) uses keys, and (b) was itself loaded from a SEF file
  • Status changed from New to In Progress
  • Applies to branch deleted (9.8)

#5 Updated by Jeremy Cronk 3 months ago

This should be all the dependencies, if you still need them.

#6 Updated by Michael Kay 3 months ago

At first sight it seems we can simply delete the line

pack.addComponent(keyComponent);

from PackageLoaderHE.readKeys(). But this will need regression testing!

#7 Updated by Michael Kay 3 months ago

  • Status changed from In Progress to Resolved
  • Applies to branch 10 added
  • Fix Committed on Branch 10, 9.9 added

Thanks for supplying the files, but I managed to create my own repro.

Patch now committed on the 9.9 and 10 branches, as described in previous comment.

#8 Updated by O'Neil Delpratt 3 months ago

  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 10.1 added

Bug fix committed in the Saxon 10.1 maintenance release.

Please register to edit this issue

Also available in: Atom PDF