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]