Compiling package to SEF fails when the package (a) uses keys, and (b) was itself loaded from a SEF file
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.
#1 Updated by Michael Kay over 1 year 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.
#3 Updated by Michael Kay over 1 year 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
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 over 1 year 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 (
#7 Updated by Michael Kay over 1 year 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.
Please register to edit this issue