commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: [digester2] should useContextClassLoader be true by default?
Date Fri, 11 Feb 2005 07:28:09 GMT
On Fri, 11 Feb 2005 20:28:06 +1300, Simon Kitching <> wrote:
> Hi y'all,
> The discussion associated with commons-configuration bugzilla entry
> has made me wonder why useContextClassLoader is false by default.
> Can anyone see a reason why it should not be *true* by default in
> digester2? (I think it's too big a jump to change the default behaviour
> of digester 1.x...).
> In other words, in what circumstances would a thread have a
> context-class-loader set, but not want to use it to load user objects?
> If they are rare, then true would seem a better default.
> I would appreciate comments from people who are familiar with frameworks
> that manipulate classloaders, esp. Tomcat (and that definitely includes
> you, Craig!).

Thanks for the vote of confidence :-)

The key issue, from a Digester perspective, is that it should work in
a non-J2EE environment as well.  We already cover half of that
equation in the current discovery logic -- if there is no context
class loader available, we fall back to the class loader from which
Digester itself was loaded.  Thefefore, even in a very simple J2SE
application (with only the system class loader being involved), we do
the right thing.

In a J2EE environemnt, this doesn't matter -- the spec requires that
it be set correctly for, for example, a webapp.  Each webapp can
presume that the context class loader will correspond to the set of
classes visible in the /WEB-INF/classes and /WEB-INF/lib directories
of that webapp (plus whatever additional classes are made visible by
the app server).

But what happens if there is a context class loader set, in a J2SE
app, but it's not the desired one?  To be honest, I haven't done much
non-J2EE development -- but I cannot think of any case where a default
to assume the context class loader was the right answer (if it is
non-null, of course) is a bad thing -- therefore, I would support the
proposal in a Digester 2.x world to make "true" the default for this,
as long as the fallback logic continued to exist.

> Thanks,
> Simon


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

View raw message