Costin Manolache wrote:
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.
A big +1 (even if I may have very little time to help the next months)
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
