tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: classloader
Date Mon, 27 Sep 2004 09:27:44 GMT
Costin Manolache wrote:

> I had a small vacation, and managed to make some of the changes in the 
> classloader/module area. I'm not completely done - but I want to 
> eventually start checking in some of the code ( if nobody objects ).
> To avoid breaking anything, I started a new package ( 
> o.a.tomcat.util.loader ), and started with the existing classes, with 
> small refactorings.
> - WebappClassLoader
> - Bootstrap
> - CatalinaProperties
> plus some extra classes to support jboss ( or m-let) style loading.
> I tried to remove all dependencies outside JDK1.4 - the package is
> very small, and I think it's ok to not use commons-logging or jmx in 
> this area. Apache.naming and jmx functionality is added via hooks - 
> after the server loader ( now "repository" ) is started.
> I think this will improve a bit the code structure - currently we have 
> a bit of a mess in how we select some classes in the bin/ jars.
> I'm not planning any change in the existing code - except adding few 
> classes and code to allow the new loader to be used ( as an option ) 
> instead of the old one.
> My goal ( which is not yet completely done ) is to support "modules" for
> connectors/interceptors/etc - with reloading and all the cool stuff, 
> and make this integrable with existing systems ( jboss, other jmx/mlet 
> based  applications, eclipse ). Instead of having the entire tomcat as 
> one chunk of code ( plus all the depenencies ) integrated in one 
> plugin, it should be possible to add a smaller subset and then have 
> connectors/auth/etc as separate plugins.
> Please let me know if this is ok with you - I'll have another long 
> trip in mid Oct. and I hope to get this done, but if there are 
> problems with what I'm trying to do ( or conflicts with other plans ), 
> I would appreciate feedback before I waste the time :-) 

In the same spirit, for better application server integration, I was 
thinking about abstracting the access to JMX features to make it 
pluggable. This deals with:
- the model MBean implementation, assuming the alternate implementation 
has the same way of delegating MBeanRegistration to the resource, and is 
supplied appropriate descriptors for the bean types
- access to the MBean server (which is hardcoded to use the default 
server at the moment)
For example, in JBoss, this would (I hope ;) ) allow using XMBeans as 
the model MBeans implementation, replacing commons-modeler.


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

View raw message