commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Luehe <Jan.Lu...@Sun.COM>
Subject Re: [digester] Re: Classloading regression between commons-digester-1.0 and later versions
Date Mon, 03 Oct 2005 22:47:35 GMT
Hi Robert,

robert burrell donkin wrote On 10/01/05 11:11,:
> hi jan
> please remember to add the subject prefix for the component.

will remember from now on! :)

> On Thu, 2005-09-29 at 13:57 -0700, Jan Luehe wrote:
>>This may be an old topic, but it seems a classloading regression was
>>introduced between commons-digester-1.0 and later versions (including
>>the most recent).
> this is indeed a very old topic :)
> <snip>
>>Can someone explain to me the motivation for setting the
>>"useContextClassLoader" property to FALSE by default?
> i can offer you nothing more than the logs: it is set to FALSE by
> default for no very good reason but most likely since it was felt
> (rightly or wrongly) to preserve backwards compatibility.
>>We can easily restore the commons-digester-1.0 behaviour in our own
>>code by setting "useContextClassLoader" to TRUE on the Digester
>>instances we acquire. However, this is not possible on "foreign" code
>>that we bundle.
>>It would be useful if Digester.getClassLoader() would also consider a
>>system property (in addition to its own "useContextClassLoader"
>>property) when determining whether to use the context classloader.
> +1
> can anyone think of any reasons not to add this?

The only problem with adding a system property for this purpose
is that it would require granting the commons-digester jar the
permission to read it. It a web application bundles commons-digester
locally, it will not have this permission in most cases.

Perhaps it is safer to stick to the current "useContextClassLoader"
property and require that web applications always bundle
commons-digester, in which case the classloader that loaded
Digester.class will correspond to the web application's classloader,
which has access to all classes under WEB-INF/lib[classes].



>>Any comments appreciated.
> submit a patch :)
> - robert

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

View raw message