Bug #4532
closedCompiling package to SEF fails when the package (a) uses keys, and (b) was itself loaded from a SEF file
100%
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.
Files
Updated by Michael Kay over 4 years 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.
Updated by Michael Kay over 4 years 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.
Updated by Michael Kay over 4 years 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.
Updated by Michael Kay over 4 years 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)
Updated by Jeremy Cronk over 4 years ago
- File string.xsl string.xsl added
- File al3-dictionary.xsl al3-dictionary.xsl added
- File al3-meta-info.xsl al3-meta-info.xsl added
- File array.xsl array.xsl added
- File map.xsl map.xsl added
This should be all the dependencies, if you still need them.
Updated by Michael Kay over 4 years ago
At first sight it seems we can simply delete the line
pack.addComponent(keyComponent);
from PackageLoaderHE.readKeys()
. But this will need regression testing!
Updated by Michael Kay over 4 years 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.
Updated by O'Neil Delpratt over 4 years ago
- % Done changed from 0 to 100
- Fixed in Maintenance Release 10.1 added
Bug fix committed in the Saxon 10.1 maintenance release.
Updated by O'Neil Delpratt about 4 years ago
- Status changed from Resolved to Closed
- Fixed in Maintenance Release 10.2, 9.9.1.8 added
- Fixed in Maintenance Release deleted (
10.1)
Bug fix applied on the Saxon 9.9.1.8 maintenance release.
Please register to edit this issue