commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Stansberry <>
Subject Re: [logging] demonstration code
Date Wed, 23 Mar 2005 06:36:04 GMT

--- robert burrell donkin <> wrote:
> On Sun, 2005-03-20 at 22:22 -0800, Brian Stansberry
> wrote:
> > --- robert burrell donkin
> > <> wrote:
> > > inspired by ceki's examples, i've been working
> on an
> > > extended systematic
> > > analysis of the various classloader cases.
> there's
> > > demonstration code
> > > for them as well as documentation.  
> > 
> > Look forward to seeing this.  I was thinking of
> > getting going on some unit tests based on the
> earlier
> > analyses, but think I'll wait a bit to see what
> you've
> > done.
> i would recommend waiting.
No problem.

> it should be quite easy to add extra analysis cases
> in the same style to
> the code base when it's done. i haven't covered much
> of the ground you
> had started to explore (nor the ground suggested by
> simon concerning
> unconventional classloaders). it would great if
> these could be added.
> it may be a day or three before it's ready. i don't
> particularly want to
> rush. it's easy to make mistakes when analysing
> these issues and it's
> easy to then build misleading arguments upon shaky
> foundations. 


>i hope
> that people will bring any mistakes i make to our
> attention as quickly
> as possible. 
> i haven't heard any feedback about:
> i'll be relying on
> the concepts and terminology outlined there in the
> analysis and
> demonstration code. again, i'd like to encourage
> anyone who finds any
> inaccuracies to speak up as soon as possible.

Looks good and is much appreciated.  I expect when I
get into classloading discussions at work I'll refer
people to that page as an excellent reference
document.  In discussions on this list I'm sure the
precision of using terms like "defining classloader"
vs "initializing classloader" will at times come in

This is a bit of a nit, but one thing I noticed was
the emphasis on "creator" and "created" in the
discussion of the thread context class loader. 
Setting of the TCCL is not necessarily closely
associated with thread creation but can also be
associated with thread execution crossing a
significant application boundary.  For example in
Tomcat a pool of threads is created (I believe by the
connector code).  Not sure if any TCCL is set at that
point, but if one is it's for sure not any web app's
classloader.  Once a thread has been assigned to
handle a request, execution moves through the various
TC container layers (Engine, Host) and only when
execution is about to enter the Context layer is the
TCCL set to the web app's classloader.  When the call
to the Context layer returns the TCCL is set back to
what it was before.  A similar approach is followed in

Interestingly, the Javadoc for
Thread.setContextClassLoader() itself emphasizes the
relationship between thread creation and setting the
TCCL, but this is somewhat misleading.


Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site! 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message