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 catalina.property 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
+1
Amy
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
