There are several things we discussed last week, and few seem to have enough consensus. This is an initial proposal - I expect it to change quite a bit. I think it's very important and will affect almost everyone - so please send at least a numeric vote, and if possible comments or sugestions. If we do agree - we'll need to also do the work, so please indicate if you are willing to write at least some of the code :-)
We seem to agree on having a more modular tomcat, where different components can be added ( by a script, manually, etc ) or removed easily. The mechanisms of adding/removing components is a separate issue that can be decided in a separate thread. My initial proposal is: 1. Add a new plugins/ directory. All tomcat components will eventually be migrated from server/lib and common/lib into one of the plugins subdirectories. ( it can be called modules/ or something else ). 2. The "profile" will consist of a list of plugins that are enabled. This can be configured using an XML file or using an API ( details of this are a separate item ). Tomcat will _not_ load all plugins automatically ( like in webapps/ or tomcat33 modules ), you'll have to explicitely add each of them. 3. The format of a plugin. We should support at least .war ( tomcat already have all the code ). I don't see a need for a format that is very different, but we (may) need to add an additional XML file. We should also be able to support a .jar format ( maybe with an additional .xml descriptor in META-INF ) as well as .xml descriptors in the plugin directory. 4. Each plugin will define one or several MBeans. Regular JMX API will be used to add/remove plugins, and the normal JMX notifications will be used to detect and plug the plugins into the server. It should be possible for an application embeding tomcat to add MBeans from any other locations. 5. The XML should be similar with the MLET format ( with some extensions if we need to ). I don't see any need for something more complicated or different. 6. Each classloader in tomcat will be ( or have ) a MBean. Different plugins can define new classloaders ( by using an mbean declaration ) or add jars to existing classloaders ( in particular the server, common and individual webapp loaders ). 7. Tomcat startup will be modified to start with only JMX and whatever minimal code we need to load plugins. The common and server loaders will be defined by the plugins. All classloader configuration will be consolidated. The ant startup will also be changed to use the same xml format ( <mbean, etc ). 8. Tomcat should work with no config file - using only JMX API calls to load it and configure a set of plugins ( profile ), using whatever class loader and layout the embeding application ( ant, etc ) wants. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
