Bug #3835
closed
Saving a compiled XSL throws NullPointerException
Applies to branch:
9.8, trunk
Fix Committed on Branch:
9.8, trunk
Fixed in Maintenance Release:
Description
Saving a compiled XSL generates a NullPointerException :
Caused by: java.lang.NullPointerException
at net.sf.saxon.trans.rules.Rule.export (Rule.java:164)
at net.sf.saxon.trans.SimpleMode$5.processRule (SimpleMode.java:1051)
at net.sf.saxon.trans.SimpleMode.processRuleChain (SimpleMode.java:1153)
at net.sf.saxon.trans.SimpleMode.processRules (SimpleMode.java:1085)
at net.sf.saxon.trans.SimpleMode.processRules (SimpleMode.java:1067)
at net.sf.saxon.trans.SimpleMode.exportTemplateRules (SimpleMode.java:1056)
at com.saxonica.ee.trans.ModeEE.exportTemplateRules (ModeEE.java:302)
at net.sf.saxon.trans.Mode.export (Mode.java:578)
at net.sf.saxon.expr.Component.export (Component.java:205)
at com.saxonica.ee.trans.StylesheetPackageEE.export (StylesheetPackageEE.java:104)
at com.saxonica.ee.trans.StylesheetPackageEE.export (StylesheetPackageEE.java:43)
at net.sf.saxon.s9api.XsltExecutable.export (XsltExecutable.java:147)
at net.sf.saxon.s9api.XsltExecutable.export (XsltExecutable.java:124)
Project is quite complex, but is made available to reproduce problem. See pom.xml:40 where the xsl to compile is defined. It is src/main/xsl/sas/dalloz/ouvrages/ouvragesDalloz2editorialEntity.xsl.
Complete Java code is available here : https://github.com/cmarchand/xslCompiler-maven-plugin/blob/master/src/main/java/top/marchand/xml/maven/plugin/xsl/AbstractCompiler.java row 95
This problem was first exposed on Saxon mailing list : https://saxon.markmail.org/search/?q=#query:%20list%3Anet.sourceforge.lists.saxon-help+page:2+mid:3fwkboxydrvwasi3+state:results
Files
- Description updated (diff)
The problem doesn't seem to happen when running from the command line.
I'm battling with trying to get this running in a Maven/IntelliJ project, largely a result of my Maven inexperience. (Our normal policy is that we don't run things that have dependencies on components that aren't part of our normal platform, but I think we need to widen the set of technologies we're prepared to use just a little bit). So it might take a few days especially as I'm taking some leave over the next week.
Note that when running from the command line we get a lot of warnings of the form
Stylesheet module
file:/Users/mike/bugs/2018/marchand3835/test/src/main/xsl/xslLib/xslLib/els-log.xsl is
included or imported more than once. This is permitted, but may lead to errors or
unexpected behavior
and I suspect this is related.
When this happens we typically have multiple instances of the same template rule that are identical except for their import precedence, but we need to retain them all so that xsl:next-match and xsl:apply-imports work correctly. This adds considerable complexity to the export process. The Java-driven process could differ from the command line process either (a) because base URIs are not known (or are different - I see that a catalog-based URI resolver is in use), or (b) because things are being processed in a different order.
The stack frame suggests that we are trying to export a template rule that has not been fully compiled: that's about all we can tell without reproducing it in a debugger.
- Status changed from New to AwaitingInfo
- Assignee set to Michael Kay
I'm sorry, I'm going to have to ask you to reproduce this in a simpler environment. I don't think it should be difficult for you to cut it down to a simple Java method that calls Saxon directly with the right parameters, without going through all the Maven plugins and catalog resolvers. I've spent an hour trying to get all your machinery working without getting as far as it calling Saxon, and that doesn't seem a productive use of time given that the eventual call on Saxon is really quite simple (I haven't even yet found the catalog that the catalog resolver is supposed to be using...)
Hello Mike,
attached a new Maven project with a java class that reproduces the problem. Be aware that xf-common.xsl has been changed compared to previous project.
You'll have to change dependencies for Saxon-EE and saxonee-license, but I'm sure you'll be able to do it. If not, just copy a valid licence file in src/main/resources and remove the dependency to saxonee-license, and install a saxonee artifact to your local repository :
mvn install:install-file -Dfile=<path-to-file> -DgroupId=extern.net.sf.saxon -DartifactId=saxonee -Dversion=9.8.0.12 -Dpackaging=jar
If you change the groupId, don't forget to change it also in pom file, line #18.
Once all this done, you'll be able to debug the Main class in your prefered IDE.
- Category set to XSLT export
- Status changed from AwaitingInfo to In Progress
- Priority changed from High to Normal
Thanks, problem now reproduced.
The template on which it fails is this one on line 333 of xf-sas-common.xsl
<xsl:template match="comment()" mode="#all" priority="2">
<xsl:copy/>
</xsl:template>
So I think we can assume it's a mode="#all" issue.
The mode we are exporting at the time is xfRes:EL_TEE_outilsReferences.getCalculatedMetatada. Although this looks suspiciously like a misspelling (for ... Metadata), there's nothing obviously wrong with this mode: it contains one template rule, and there is one xsl:apply-templates instruction that invokes this mode.
The NPE occurs because the Template in question has no StackFrameMap. However, everything else about the Template is wrong too: for example the pattern and the body are both null. The template clearly hasn't been properly initialised.
It seems the code makes no attempt to ensure that a template rule is initialized (compiled) before being exported. All our tests apparently rely on setting XsltCompiler.setJustInTimeCompilation(false) if they are going to call export() to generate a SEF file.
I've tried making export() on a template rule call initialize() to force compilation, but that gives a ConcurrentModificationException on the component index because compiling a template can cause new components to be identified (inline functions, global variables).
So the workaround is to add the line
compiler.setJustInTimeCompilation(false);
immediately after initialising the compiler.
I think the simplest fix is going to be to make this a requirement: document that export() is only allowed if JIT compilation is disabled, and enforce this restriction.
- Status changed from In Progress to Resolved
- Applies to branch trunk added
- Fix Committed on Branch 9.8, trunk added
Resolved by requiring that if a compiled package is to be exported, just-in-time compilation must have been disabled on the compiler.
Thanks a lot !
Best regards,
Christophe
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.8.0.14 added
Bug fix applied in the Saxon 9.8.0.14 maintenance release.
Please register to edit this issue
Also available in: Atom
PDF
.