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?"







Reply via email to