Craig R. McClanahan wrote:
>
> On Wed, 30 May 2001, Scott Sanders wrote:
>
>
>> Craig will correct me if I am wrong, but the idea is that in a server
>> environment, the server container *may* set the conxtext class loader
>> for you (at the webapp level, presumably). I am under the assumption
>> that this is done so that you can completly seal one webapp off from
>> another at a class access level.
>>
>
>
> That's part of it. The other reason is that it allows the digester code
> itself to be loaded from a shared classloader, but still create user
> objects from the thread context class loader. In a servlet environment,
> that would mean the class loader associated with your web app, so it would
> have access to /WEB-INF/classes and /WEB-INF/lib.
>
> However, the argument to do this unilaterally is much weaker when you take
> Digester out of its original home (Struts, which was by definition
> interested only in a web application world) and propose it as a general
> purpose class library. Maybe we should have a boolean property to define
> whether it does this or not? I think defaulting to true would be fine --
> but people should be able to turn it off if their environment sets the
> thread context class loader to something not useful.
Fair enough. I will add the property to allow the ability to NOT use
the context class loader.
I was probably being a little myopic anyway in that I only have use for
Digester at the moment in a web application environment.
Scott Sanders
