[digester2] should useContextClassLoader be true by default?

[Simon Kitching <sk...@apache.org>]

Hi y'all,

The discussion associated with commons-configuration bugzilla entry
http://issues.apache.org/bugzilla/show_bug.cgi?id=33475
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,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [digester2] should useContextClassLoader be true by default?

[Craig McClanahan <cr...@gmail.com>]

On Fri, 11 Feb 2005 20:28:06 +1300, Simon Kitching <sk...@apache.org> wrote:
> Hi y'all,
> 
> The discussion associated with commons-configuration bugzilla entry
> http://issues.apache.org/bugzilla/show_bug.cgi?id=33475
> 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

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org