Project

Profile

Help

Bug #4114

closed

XSLT pipeline : Error XPDY0002 - The context item for axis step fn:root(…)/element() is absent

Added by hamdi karray almost 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
s9api API
Sprint/Milestone:
Start date:
2019-01-28
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.9, trunk
Fix Committed on Branch:
9.9, trunk
Fixed in Maintenance Release:
Platforms:

Description

Hi,

I create this ticket as support one first but it seems to be a bug : when i set a traceListener for my XsltTransformer (s) in a pipeline, i get the following errors. Otherwise, the folllowing works fine


Please, I need some help dealing with saxon api :) I create a pipeline with 2 XsltTransform of the same xslt and when i run transform i get this error :

2019-01-24 11:32:15,673 [pool-2-thread-1] INFO e.s.e.x.XsltListener - file
2019-01-24 11:32:15,674 [pool-2-thread-1] INFO e.s.e.x.XsltListener - Error 
XPDY0002 while evaluating xsl:message content: The context item for axis 
step fn:root(...)/element() is absent
here is my xslt :
<xsl:stylesheet exclude-result-prefixes="#all" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
<xsl:variable name="supp" as="xs:string" select="root()/*/name()"/>

<xsl:template match="/">
    <xsl:message select="$supp"/>
    <file/>
</xsl:template>
</xsl:stylesheet>

the first XsltTransform work fine but It seems that i have no context node during the second XstTransform running.

I use :

transformer1.setSource(source) : source is a SAXSource

transformer1.setDestination(transformr2)

transformr2.setDestination(serialiser)

According to documentation (XsltTransform.setInitialContextNode): This value is ignored in the case where the XsltTransformer is used as the Destination of another process. In that case the initial context node will always be the document node of the document that is being streamed to this destination.

Thanks for your Help


Related issues

Copied from Saxon - Support #4109: XSLT pipeline : Error XPDY0002 - The context item for axis step fn:root(…)/element() is absentClosedMichael Kay2019-01-24

Actions
Actions #1

Updated by hamdi karray almost 6 years ago

  • Copied from Support #4109: XSLT pipeline : Error XPDY0002 - The context item for axis step fn:root(…)/element() is absent added
Actions #2

Updated by Michael Kay almost 6 years ago

  • Fixed in Maintenance Release deleted (9.9.0.2)

I'm sorry for the delay in responding to this. I just realised that it wasn't on my list because it was erroneously flagged as "fixed in maintenance release". I've now cleared that flag.

Actions #3

Updated by Michael Kay almost 6 years ago

  • Priority changed from High to Normal

I haven't been able to reproduce this problem. I'm using this unit test, which succeeds:

public void testPipelineWithGlobalContextItem() {
	    // bug 4114: stylesheet in pipeline has global variable that uses the context item
        String xsl = "<xsl:stylesheet exclude-result-prefixes=\"#all\" xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\" version=\"2.0\">\n"
                + "<xsl:variable name=\"supp\" as=\"xs:string\" select=\"root()/*/name()\"/>\n"
                + "\n"
                + "<xsl:template match=\"/\">\n"
                + "    <xsl:message select=\"$supp\"/>\n"
                + "    <file/>\n"
                + "</xsl:template>\n"
                + "</xsl:stylesheet>\n";

        try {
            // common processor
            Processor processor = new Processor(false);

            // transformer1
            XsltCompiler xslt_compiler1 = processor.newXsltCompiler();

            XsltExecutable exec = xslt_compiler1.compile(new StreamSource(new StringReader(xsl)));

            XsltTransformer xslt_transformer1 = exec.load();
            xslt_transformer1.setSource(new StreamSource(new StringReader(xsl))); // itself


            // transformer2
            XsltTransformer xslt_transformer2 = exec.load();

            // transformer2's destination
            Serializer destination2 = processor.newSerializer(System.out);
            xslt_transformer2.setDestination(destination2);

            // transformer1's destination
            xslt_transformer1.setDestination(xslt_transformer2);

            xslt_transformer1.transform();
        } catch (SaxonApiException e) {
            e.printStackTrace();
            fail();
        }
    }

Could you please supply a repro that demonstrates the failure?

Actions #4

Updated by Michael Kay almost 6 years ago

I also tried it with a TraceListener like this:

public void testPipelineWithGlobalContextItem() {
	    // bug 4114: stylesheet in pipeline has global variable that uses the context item
        String xsl = "<xsl:stylesheet exclude-result-prefixes=\"#all\" xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\" version=\"2.0\">\n"
                + "<xsl:variable name=\"supp\" as=\"xs:string\" select=\"root()/*/name()\"/>\n"
                + "\n"
                + "<xsl:template match=\"/\">\n"
                + "    <xsl:message select=\"$supp\"/>\n"
                + "    <file/>\n"
                + "</xsl:template>\n"
                + "</xsl:stylesheet>\n";

        try {
            // common processor
            Processor processor = new Processor(false);

            // transformer1
            XsltCompiler xslt_compiler1 = processor.newXsltCompiler();
            xslt_compiler1.setCompileWithTracing(true);

            XsltExecutable exec = xslt_compiler1.compile(new StreamSource(new StringReader(xsl)));

            XsltTransformer xslt_transformer1 = exec.load();
            xslt_transformer1.setSource(new StreamSource(new StringReader(xsl))); // itself
            xslt_transformer1.setTraceListener(new AbstractTraceListener() {
                @Override
                protected String getOpeningAttributes() {
                    return "";
                }

                @Override
                protected String tag(int construct) {
                    return "E" + construct;
                }
            });


            // transformer2
            XsltTransformer xslt_transformer2 = exec.load();

            // transformer2's destination
            Serializer destination2 = processor.newSerializer(System.out);
            xslt_transformer2.setDestination(destination2);
            xslt_transformer2.setTraceListener(new AbstractTraceListener() {
                @Override
                protected String getOpeningAttributes() {
                    return "";
                }

                @Override
                protected String tag(int construct) {
                    return "F" + construct;
                }
            });

            // transformer1's destination
            xslt_transformer1.setDestination(xslt_transformer2);

            xslt_transformer1.transform();
        } catch (SaxonApiException e) {
            e.printStackTrace();
            fail();
        }
    }


Actions #5

Updated by Michael Kay almost 6 years ago

I now notice that although the test runs to completion, the xsl:message does generate an error message, which doesn't cause a fatal termination:

Error XPDY0002 while evaluating xsl:message at line 5 of : The context item is absent

I changed the xsl:message to xsl:comment and the failure becomes more visible.

Actions #6

Updated by Michael Kay almost 6 years ago

Looks like I failed to update this tracker to record progress on this.

I made a change to AbstractXsltTransformer.getReceivingTransformer() that fixes this test case. But before committing the change, I need to check one or two regression test failures to be confident that they aren't related.

Actions #7

Updated by Michael Kay almost 6 years ago

  • Status changed from New to Resolved
  • Applies to branch trunk added
  • Fix Committed on Branch 9.9, trunk added

The test regressions turned out to be caused by the changes for bug #4137, so I am now committing this change.

Actions #8

Updated by O'Neil Delpratt almost 6 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.9.1.2 added

Bug issue fixed in the Saxon 9.9.1.2 maintenance release.

Please register to edit this issue

Also available in: Atom PDF