Chris,

As I have mentioned earlier, I have following code in one of the
"finally" blocks.

Field dbfield =
ReflectionUtil.getDeclaredField(XMLUtils.class,
                                "documentBuilder");
                ThreadLocal db = (ThreadLocal) dbfield.get(null);
                if (db != null) {
                        db.remove();
                }
This code seems to do the job that I wanted, which is cleaning the
threadlocal.

As I am using reflection, I am wondering if I am clearing the
ThreadLocal pertaining to the thread I am currently in or "any"
threadlocal that might have been created by a different thread.

Thanks

Srikanth

On 12/13/10 12:56 PM, Ebert, Chris wrote:
> I haven't solved this specific issue but (when the object isn't directly 
> accessible, which I assume is the case) you could:
> 
> 1) find the nearest accessible object to the field you want.
> 2) get the field value using reflection, setting accessibility if need be.
> 3) Do what you need to: clear the thread local, or store it in something that 
> will clear it, or at least expose the number of entries to your monitoring 
> system. Or replace it with a class that will cache things properly (bounded, 
> with well defined rules).
> 3a) At the very least, once I have the thread local I can wrap some logging 
> around it and see where objects are coming in and going out. Often, it's a 
> fault in the application (a missed 'close' or other operation because 
> something wasn't wrapped in a try/finally.) No substitute for figuring out 
> what the problem really is.
> 
> Sometimes I find out things about how stuff is initialized that I didn't want 
> to know, but there it is.
> 
> Oh, and add a unit test to see that your fix actually works and keeps 
> working. You never know when someone will update the library, actually. It 
> might be you, a few months later... 
> 
> You might be able to solve the problem by clever swapping of some class in 
> the wsdd file (client or server, as appropriate) but figuring it out might 
> take a while, and unit testing the WSDD config often is harder than a bit of 
> reflection. Replacing a few implementations in the WSDD just so you can get a 
> particular bit of the Axis library to log the info you want is a little 
> convoluted, but I do it a lot 'cause Axis doesn't do lots of things the way I 
> want it to.
> 
> Chris
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to