Proposal: removing ServletLoader

[co...@eng.sun.com]

Hi,

History: ServletLoader was added in order to modularize the class loading
and allow us to replace the 3.0 mechanism ( hardcoded class loader) with 
AdaptiveClassLoader. The idea was to have a smooth "evolution" by
rewriting or replacing individual components while maintaining
the code stability ( the old code is removed only after the new code have 
enough testing and we trust it ).

So far we had 2 ServletLoader implementations - the original tomcat3.0 and
the one acting as an adapter to AdaptiveClassLoader from JServ1. Since ACL
provided more features and was the only one actively maintained, the
original class loader was removed. 

The interface itself was based on the existing requirements and
interactions. Reloading was added on top of that. Most of the methods are
not needed and right now the interface feels very complex.

Proposal:

1. Separate reloading from class loader. The current prototype (
DependManager, with DependClassLoader adapter and ReloadInterceptor) shows
that this can be done, and allows far more control ( detect changes in
web.xml, detect changes in tomcat, etc).

2. ClassLoaders will just implement class loading. It is a complex
operation and shouldn't be mixed with anything else. We also want to keep
the ClassLoader independent of tomcat - it can implement any loading
policy it wants, but it shouldn't use internal interfaces or implement
tomcat-specific functionality.  

3. remove ServletLoader. The ContextInterceptor provides enough
control to implement the equivalent functionality.

4. ClassLoader will be pluged in using ContextInterceptor, and the reload
callback to deal with context reload. 

Please let me know if you have any code that depends on ServletLoader, we
can keep it longer if you need that. If nobody objects we can just remove
it.

Costin