tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amy Roh <>
Subject Re: [PROPOSAL][TOMCAT5] plugins directory
Date Mon, 16 Dec 2002 20:58:08 GMT
>> 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 :-)
> I will have time to work on 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 ).
> +1. For security reason, we should have a way to protect the module 
> (using Remy's mechanism). We should have trusted 
> components as well as untrusted.
> What about Xerces? It's a kind of pluging but it is also and endorsed 
> lib. We need to keep the endorsed folder/mechanism
>> 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.
> I recommend keeping war file for web applications, and use jar as the 
> standard module/component. In module implements a common interface for 
> identifying themself, I recommend we don't add another xml file but use 
> introspection to discover the module functionalities etc.
>> 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.
> +1. We will have to document that parts to avoid confusion.
>> 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 ).
> We should define a contract between Tomcat and the plugins which force 
> the plugin-defined classloader to be "secure" (at least do the package 
> protection check). Maybe plugin-defined classloader should extend some 
> catalina classes in order to fullfill the contract.
> If a component doesn't have an MBean, we should have a mechanism to 
> generate, using introspection, that MBean. We doesn't need that soon, 
> but we you keep the idea in mind...
>> 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. 
> Questions: Are we considering a Valve as a module/component? And it is 
> not clear in your proposal if we are keeping the server.xml file. I 
> recommend we keep it just to avoid confusion (IMBW...we should have a 
> pool to determine if users like server.xml :-) ).
> -- Jeanfrancois
>> Costin



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

View raw message