Well, then we would also have to track the DTMManager in XRTreeFrag, which is already too bloated with member variables. Each instance could make a new member of XPathContext... this might be the better choice. But a bigger change than I want to make right now.
For right now, I just put in a check in destruct() to make sure the DTM is in the manager. I chose this because it is fairly localized and high level. On the other hand, I'm worried about performance implications. An alternative would to to check in DTMManagerDefault#release() to make sure the DTM being nulled is the actual DTM that is requested for removal. This is better for performance, but is a lower level kind of hack. Other resource deletions at the level of XRTreeFrag could have similar problems. A bad alternative, but the proper one architecturally in a sense, is to keep track of the XRTreeFrag DTMs, and do the deletion explicitly at choice points and exit. -scott "Joseph Kesselman/CAM/Lotu To: "Scott Boag/Cambridge/IBM" <[EMAIL PROTECTED]> s" cc: "Frank E. Weiss" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] <joseph_kesselman@ Subject: Re: Stylesheet Reuse NullPointerException us.ibm.com> 04/02/2002 02:35 PM Scott's diagnosis makes sense to me. Simplest fix might be for each transform() call to allocate a new DTMManager, so the late finalizers could negotiate with the old one without any interaction with the new transformation. Best fix might be to improve our scoping to eliminate the need for the finalizer. It's generally not a good idea to rely on finalizers anyway. "What a tangled web we weave..." "Oh, you're a programmer?"