On Fri, 11 Feb 2005 20:28:06 +1300, Simon Kitching <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
