Saxon

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.

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.

Thanks a lot !

Best regards, Christophe