Re: Grasping at Straws: Consistent but Mystifying Failure for Saxon 9.5
Michael Kay <mike-JkSD5nQpfvpWk0Htik3J/[email protected]>
| Newsgroups | gmane.text.xml.saxon.help |
|---|---|
| Message-ID | <[email protected]> |
If writing to the standard Saxon output from a MessageListener ever worked, then it certainly only worked by accident rather than by design! Intrinsically, though, it's a useful option - I often find it useful to generate comments in the output file as an alternative to generating messages; the great advantage is that they then appear "in context". It's not so useful, though, if you're constructing a variable at the time. Michael Kay Saxonica > On 24 Jul 2020, at 17:10, Eliot Kimber <ekimber-xb9TSTQ6enFWk0Htik3J/[email protected]> wrote: > > Removing some xsl:message statements from my transform removed the failure. > > Our code does create a message listener, which extends SaxonMessageListenerBase and then uses a SaxonStringLogger() to write to the normal Saxon output, in addition to writing to a Log4J log. This is the base message listener this code has used for a very long time. > > I suspect this is a side effect of some subtle bug in Saxon 9.5.1.10 that was almost surely fixed in some later version. > > In any case, the messages are only for debugging so turning them off is an acceptable solution. > > Cheers, > > E. > > -- > Eliot Kimber > http://contrext.com > > > On 7/23/20, 5:36 PM, "Eliot Kimber" <ekimber-xb9TSTQ6enFWk0Htik3J/[email protected]> wrote: > > Thanks--that seems concrete enough to pursue on my end. > > Cheers, > > Eliot > -- > Eliot Kimber > http://contrext.com > > > On 7/23/20, 4:54 PM, "Michael Kay" <mike-JkSD5nQpfvpWk0Htik3J/[email protected]> wrote: > > It's executing an xsl:message instruction, and it's crashing because the message output is being sent to a tree builder whose nodeFactory field is null; it's set to null when the tree builder is closed, so it looks like the builder has been closed, and then more content has been written to it. > There's a MessageListenerProxy on the stack, and as far as I can see a MessageListenerProxy only gets created if there's a user-application call on XsltTransformer.setMessageListener(). So I'd be looking to see if the application is setting a MessageListener, and if so, what it actually does. > > The MessageListenerProxy builds the message as a tree (most xsl:message content is just character data, but in the general case a message is an XML document), and when the tree is complete it calls the user-supplied MessageListener.message() method. > > Michael Kay > Saxonica > > > On 23 Jul 2020, at 21:32, Eliot Kimber <ekimber-xb9TSTQ6enFWk0Htik3J/[email protected]> wrote: > > In the context of the RSuiteCMS application, we have custom code that uses Saxon EE 9.5.1.10 to run a transform. > > The same transform-running class is used from two different other class--one always works and one consistently fails on some, but not all, input. The transform itself has been in constant successful use for a couple of years. > > It is not in my power to upgrade the Saxon version. > > I tried debugging using the HE source but the running EE code diverges from HE so that's not really practical. > > I'm assuming that it must be something about the local Java environment when the failing code calls transform--I can't think of anything in the source data or style sheet that would cause the failure below, so it must be some non-obvious difference in the calling code that is tripping over this failure. > > My question: given the exception trace below, is there any idea what the cause of this error might be or does the fact that it happens in once code path context but not another for the same inputs provide clue? > > The line reported in the trace, dita2htmlImpl.xsl:202, is : > > <xsl:sequence select="$out"> > > Where $out is: > > <xsl:variable name="out" as="element()"> > <xsl:apply-templates select="$base-result" mode="change-tc-markup-in-merge-regions"/> > </xsl:variable> > > Line 202 is the last executed line in the transform and since $out is a variable it means that all the processing actually happens when $out is sent to the result. > > It looks like the failure is in the output serializer: > > Line 296 of LinkedTreeBuilder is: > > TextImpl n = nodeFactory.makeTextNode(currentNode, chars); > > I can debug through the source code but I can't right now devote the time needed to make the Saxon code into a working Eclipse project so I can set a conditional breakpoint on it, so I was hoping the error itself would point in the direction of what's wrong in our calling code... > > Thanks, > > Eliot > > Here is the trace: > > 2020-07-23 13:50:01.451 rsuite-server ERROR [http-bio-8080-exec-971] <RestAPIv1.req-10623> gov.gao.newblue.rsuite.domain.links.LinkFactory - null > java.lang.NullPointerException > at net.sf.saxon.tree.linked.LinkedTreeBuilder.characters(LinkedTreeBuilder.java:296) > at net.sf.saxon.event.ProxyReceiver.characters(ProxyReceiver.java:193) > at net.sf.saxon.event.ComplexContentOutputter.characters(ComplexContentOutputter.java:168) > at net.sf.saxon.event.SequenceWriter.characters(SequenceWriter.java:272) > at net.sf.saxon.s9api.MessageListenerProxy.characters(MessageListenerProxy.java:92) > at net.sf.saxon.event.TreeReceiver.characters(TreeReceiver.java:246) > at net.sf.saxon.event.TreeReceiver.append(TreeReceiver.java:295) > at net.sf.saxon.expr.instruct.Message$AttributeMasker.append(Message.java:369) > at net.sf.saxon.expr.instruct.Message.processLeavingTail(Message.java:285) > at net.sf.saxon.expr.instruct.Instruction.process(Instruction.java:138) > at net.sf.saxon.expr.instruct.Instruction.evaluateItem(Instruction.java:334) > at gen_CompiledBlockIterator_132412.next(rsuite:/res/plugin/gao-newblue/xslt/dita2xhtml/dita2htmlImpl.xsl:65535) > at net.sf.saxon.expr.CardinalityCheckingIterator.<init>(CardinalityCheckingIterator.java:53) > at CE__Slash__1324051688325951.process(rsuite:/res/plugin/gao-newblue/xslt/dita2xhtml/dita2htmlImpl.xsl:202) > at com.saxonica.bytecode.CompiledExpression.process(CompiledExpression.java:61) > at net.sf.saxon.expr.instruct.Template.applyLeavingTail(Template.java:241) > at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:1063) > at net.sf.saxon.Controller.transformDocument(Controller.java:2089) > at net.sf.saxon.Controller.transform(Controller.java:1912) > at com.rsicms.rsuite.utils.xml.TransformUtils.iTransform(TransformUtils.java:384) > > > -- > Eliot Kimber > http://contrext.com > > > > > > _______________________________________________ > saxon-help mailing list archived at http://saxon.markmail.org/ > [email protected] > https://lists.sourceforge.net/lists/listinfo/saxon-help > > > > > > > _______________________________________________ > saxon-help mailing list archived at http://saxon.markmail.org/ > [email protected] > https://lists.sourceforge.net/lists/listinfo/saxon-help > > > > > _______________________________________________ > saxon-help mailing list archived at http://saxon.markmail.org/ > [email protected] > https://lists.sourceforge.net/lists/listinfo/saxon-help > > > > > _______________________________________________ > saxon-help mailing list archived at http://saxon.markmail.org/ > [email protected] > https://lists.sourceforge.net/lists/listinfo/saxon-help _______________________________________________ saxon-help mailing list archived at http://saxon.markmail.org/ [email protected] https://lists.sourceforge.net/lists/listinfo/saxon-help