Hi all,
I am using Xalan-J 2.7.1 from the command line via the
org.apache.xalan.xslt.Process class. I have noticed that <xsl:message
terminate="yes"> is no longer terminating the processing of the
stylesheet. Instead the processor continues running and statements that
come after the terminating <xsl:message> get processed. The termination
is handled the way you'd expect in 2.7.0 and earlier versions.
Test stylesheet:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
<xsl:output method="text"/>
<xsl:template match="/">
<xsl:message terminate="yes">Terminating here...</xsl:message>
<xsl:value-of select="'This should not be processed!'"/>
</xsl:template>
</xsl:stylesheet>
When I run this via org.apache.xalan.xslt.Process, I get the termination
message ("Terminating here...") along with the line and column number
information, but then it continues running and I see the second line of
output ("This should not be processed!").
I understand that Process uses the DefaultErrorHandler class, and that
according to the release notes for Xalan 2.7.0 (see
http://xml.apache.org/xalan-j/readme.html, the "New default error
handling behavior" section), the default ErrorListener was changed so
that it no longer throws exceptions on errors or fatal errors. However
in 2.7.0 the org.apache.xalan.xslt.Process still worked as expected,
without any modifications.
This bug fix introduced the change in behavior of Process between 2.7.0
and 2.7.1:
http://issues.apache.org/jira/secure/ViewIssue.jspa?key=XALANJ-2317.
Process went from instantiating DefaultErrorHandler with
m_throwExceptionOnError=true to instantiating it with
m_throwExceptionOnError=false. There were good reasons (I suppose) for
making that change, but it seems to break the default handling of
<xsl:message terminate="yes">.
I was somewhat surprised to see that org.apache.xalan.xslt.Process was
showing incorrect default behavior for <xsl:message terminate="yes">
right out of the box. Is this a bug or is this known/expected and I just
need to alter Process myself or use my own error handler? I can simply
"fix" this for my own uses by changing Processs to use "new
DefaultErrorHandler(true)" but I'm worried about undoing the fixes for
the problems listed in bug #2317.
I wanted to post to the mailing list before I tried submitting a bug
report and working on a possible patch, to see if this was an actual
problem or not.
Thanks for your help,
--
Nathan Nadeau
n...@gleim.com
Software Development
Gleim Publications, Inc.
http://www.gleim.com
