Naresh Sikha wrote: > > My take on this is that the bug isn't in copyChildren logic per se, but in > expand (the copyChildren method, as is, is useful elsewhere). You'll have to > pardon the lack of a real diff (we're CVS challenged at Schwab), but here is > a proposed fix to expand. It works by literally replacing the profile > element with all of its children and then reinvokes expand on the parent > element.
There was no change to the logic of copyChildren, just to its name. If you look closely at this method, you will see that it uses appendChild. The definition of appendChild can be found here: http://nagoya.apache.org/gump/javadoc/xml-xerces2/java/build/docs/javadocs/api/org/w3c/dom/Node.html#appendChild(org.w3c.dom.Node) The important statement in that description is "If the newChild is already in the tree, it is first removed.". In short, appendChild is essentially a moveChild, meaning that the method named copyChildren effectively moved them. One fix would be to clone node prior to appending it. When I originally wrote that routine, I was very conscious of performance, but the overall performance of the jenny step has continued to be negligible, despite the amount of additions to that routine. = = = Re: the proposed fix to expand: the problem I was seeing wasn't related to profiles. Once included, the old nodes are no longer needed in their previous form. What I was seeing is that the logic I added which enabled the inheriting of dependencies effectively ended up stealing them. In any case, if you look closely at the logic you patched, a few lines down there is the logic to recurse through the children. There is no need to do this twice. - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
