Bug #1517
closedjava.lang.NullPointerException for "cast as" in AVT
100%
Description
I experience the following problem with the attached stylesheet that uses "cast as" in an attribute value template:
$ java -jar saxon9he.jar -xsl:castAsInAVT.xsl -s:castAsInAVT.xsl
java.lang.NullPointerException
at net.sf.saxon.expr.Expression.getExecutable(Expression.java:740)
at net.sf.saxon.expr.ExpressionParser.parseCastExpression(ExpressionParser.java:875)
at net.sf.saxon.expr.ExpressionParser.parseCastableExpression(ExpressionParser.java:804)
at net.sf.saxon.expr.ExpressionParser.parseTreatExpression(ExpressionParser.java:785)
at net.sf.saxon.expr.ExpressionParser.parseInstanceOfExpression(ExpressionParser.java:767)
at net.sf.saxon.expr.ExpressionParser.parseIntersectExpression(ExpressionParser.java:1263)
at net.sf.saxon.expr.ExpressionParser.parseUnionExpression(ExpressionParser.java:1245)
at net.sf.saxon.expr.ExpressionParser.parseMultiplicativeExpression(ExpressionParser.java:1181)
at net.sf.saxon.expr.ExpressionParser.parseAdditiveExpression(ExpressionParser.java:1161)
at net.sf.saxon.expr.ExpressionParser.parseRangeExpression(ExpressionParser.java:1046)
at net.sf.saxon.expr.ExpressionParser.parseComparisonExpression(ExpressionParser.java:995)
at net.sf.saxon.expr.ExpressionParser.parseAndExpression(ExpressionParser.java:568)
at net.sf.saxon.expr.ExpressionParser.parseOrExpression(ExpressionParser.java:550)
at net.sf.saxon.expr.ExpressionParser.parseExprSingle(ExpressionParser.java:474)
at net.sf.saxon.expr.ExpressionParser.parseExpression(ExpressionParser.java:418)
at net.sf.saxon.expr.ExpressionParser.parse(ExpressionParser.java:365)
at net.sf.saxon.style.AttributeValueTemplate.make(AttributeValueTemplate.java:70)
at net.sf.saxon.style.StyleElement.makeAttributeValueTemplate(StyleElement.java:560)
at net.sf.saxon.style.LiteralResultElement.prepareAttributes(LiteralResultElement.java:115)
at net.sf.saxon.style.StyleElement.processAttributes(StyleElement.java:419)
at net.sf.saxon.style.StyleElement.processAllAttributes(StyleElement.java:368)
at net.sf.saxon.style.StyleElement.processAllAttributes(StyleElement.java:376)
at net.sf.saxon.style.PrincipalStylesheetModule.processAllAttributes(PrincipalStylesheetModule.java:303)
at net.sf.saxon.style.PrincipalStylesheetModule.preprocess(PrincipalStylesheetModule.java:221)
at net.sf.saxon.PreparedStylesheet.setStylesheetDocument(PreparedStylesheet.java:340)
at net.sf.saxon.PreparedStylesheet.prepare(PreparedStylesheet.java:186)
at net.sf.saxon.PreparedStylesheet.compile(PreparedStylesheet.java:104)
at net.sf.saxon.Transform.doTransform(Transform.java:537)
at net.sf.saxon.Transform.main(Transform.java:72)
Fatal error during transformation: java.lang.NullPointerException: (no message)
I have the same problem with Saxon-PE and Saxon-EE from inside oXygen. I updated version 9.3.0.5 that came bundled with oXygen to versions 9.3.0.11 and 9.4.0.3 by replacing saxon9ee.jar in oXygen's lib directory, but the problem remains.
This looks a lot like Bug #651, but as that issue is seven years old and closed, I'm opening a new one.
Files
Updated by Thomas Weber over 12 years ago
I found that Saxon 9.0.0.4J which comes with Ubuntu 11.10 does not have this problem:
$ saxonb-xslt -xsl:castAsInAVT.xsl -s:castAsInAVT.xsl
<test xmlns:xs="http://www.w3.org/2001/XMLSchema" test="123"/>
Updated by Michael Kay over 12 years ago
- Category set to Internals
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Found in version set to 9.3
Definitely a bug. NPE from getExecutable() in the expression tree is something of a persistent problem; it arises when the optimizer does a tree rewrite and fails to leave everything consistent and tidy. I will look into it.
Updated by Michael Kay over 12 years ago
- Status changed from New to In Progress
I've confirmed that the problem is present in 9.3.0.11 and is not present in 9.4.0.3.
It's caused by a combination of factors. There's a special rule saying that cast to QName has to take a string literal as the argument, and this means that cast expressions need to be processed earlier than most other expressions, at a stage during parsing where we can still distinguish a string literal from a parenthesized string literal. So there's some early processing taking place during parsing; but when we're parsing the content of an AVT, the environment for this processing has not been set up.
As (a) this is fixed in 9.4, (b) the fix isn't easy, and (c) there's quite likely to be no further maintenance release on the 9.3 branch, I'm going to take the unusual step of proposing a "won't fix" resolution. There's an easy workaround, which is to do the cast outside the AVT and put the result in a variable.
Updated by Michael Kay over 12 years ago
- Status changed from In Progress to Resolved
- Fixed in version set to 9.4
I've committed a patch for both the 9.3 and Saxon-CE branches (the 9.3 one is tested). This will appear in any future maintenance release on the 9.3 branch. Affects module AttributeValueTemplate.
Updated by O'Neil Delpratt almost 11 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in version changed from 9.4 to 9.5.1.4
Bug fix applied in Saxon maintenance release 9.5.1.4
Please register to edit this issue