tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <>
Subject Re: [next] What's next ?
Date Fri, 03 Oct 2003 12:52:03 GMT wrote:
> On Thu, 2 Oct 2003, Angus Mezick wrote:
>>>2. Eliminate the shared and common classloader repositories.  Unless
>>>these are required by the spec?  Force webapps to be self-contained by
>>>putting all their classes in WEB-INF/lib or WEB-INF/classes of their
>>>webapp.  Have the WEB-INF/clases -> WEB-INF/lib -> endorsed -> system
>>>classloader hierarchy, much simpler than current.
>>-1 Ugh!  No.  I love the current format.  I have full control of what
>>webapps are in use on my system and I don't wish to have to maintain the
>>build config that has each of my 5 web apps copy from a central
>>repository instead of just using commons.  I find the current solution
>>rather elegant because I can use it but am not forced to.
> Ack. In contrast, I've sometimes wished to have webapp (classloader)
> hierarchies. A context nested in another context would see the outer
> classes but would be independently restartable. However, if a parent
> context is restarted, all children are restarted, too.

Recently I implemented a "Host" classloader using a Host Listener and a
custom WebappLoader. Then extended the web app manager app so that it could
reload the "Host", all its webapps, and recycle its "Host" classloader.  
This comes in handy when you want to use shared libraries for all the webapps
deployed for a host but need to be able to update them in a running container.


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

View raw message