[
https://issues.apache.org/jira/browse/XALANJ-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510508
]
Brian Minchau commented on XALANJ-2389:
---------------------------------------
I think the solution is for setParent() to set the parent unconditionally for
all nodes
except those that are top level. Top level nodes should not have their parent
reset.
Unconditionally setting the parent breaks these tests:
Fail StylesheetTestlet{trax} impincl20.xsl
Fail StylesheetTestlet{trax} mdocs12.xsl
Fail StylesheetTestlet{trax} mdocs13.xsl
I think the reason is that we re-set the parent of some top level
<xsl:template> elements, and suddently
they think they are part of the principle stylesheet, not the imported or
included one, so we get
something wrong with that.
Proposed fix is to have SyntaxTreeNode.setParent() unconditionally set the
parent for all nodes, but then undo that a little by having a new method,
TopLevelElement.setParent() that over-rides the base class method in
SyntaxTreeNode. In this way all top level elements will keep pointing to thier
original parent stylesheet node,
while others that are being messed with can be properly updated.
Bit of a hack here, but then again the code doesn't work as-is.
Test case to be attached shortly.
Thanks to Henry Zongaro for the "description" which I cut/paste from a personal
note, with some editorial changes.
Also thanks to Henry for the testcase an analysis of the setParent() issue.
> XSLTC doesn't correctly set the parent of some nodes ... comile time failures
> result
> ------------------------------------------------------------------------------------
>
> Key: XALANJ-2389
> URL: https://issues.apache.org/jira/browse/XALANJ-2389
> Project: XalanJ2
> Issue Type: Bug
> Components: XSLTC
> Reporter: Brian Minchau
>
> There is a problem with AST node construction in XSLTC.
> When the processor is creating AST nodes for path expressions,
> it sometimes discards nodes that it creates, takes the child nodes,
> and attaches them to new parents. This can happen when nodes
> representing casts are injected.
> Inside the constructors and various setter methods for SyntaxTreeNode
> and its subclasses, there are calls to setParent that try to ensure that the
> child of a node points to its parent. The problem is that
> SyntaxTreeNode.setParent checks whether the parent of a node is not null,
> and if it is, it ignores the request to set the parent.
> In the case of the path expressions, some nodes that the parser has already
> created as children of other nodes get reattached to new parents in the
> middle of parsing.
> The behaviour of the setParent method means that such nodes point to the old
> parent
> which is disconnected from the rest of the parse tree.
> Much later, when generating code for VariableReference nodes,
> we loop through the parent chain looking for the nearest ancestor
> that implements the Closure interface. Predicate is one such class.
> But this problem in SyntaxTreeNode.setParent has the result that the
> variable reference node in the test case does not find a Predicate that
> ought to be in its ancestor chain.
> The problem is to ensure the SyntaxTreeNode._parent pointer is correct.
> It's not a simple matter of changing SyntaxTreeNode.setParent to
> unconditionally set the _parent field however. If you do that, other things
> end up being broken.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
