Re: [PROPOSAL][TOMCAT5] plugins directory

[Remy Maucherat]

Jeanfrancois Arcand wrote:

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 :-)

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.

I imagine the catalina.properties would disappear (at least, the classloader related sections).

What about Xerces? It's a kind of pluging but it is also and endorsed lib. We need to keep the endorsed folder/mechanism

Due to the way the JVM works (the problems we're running into with the XML parser prove that the Sun's "bundle everything" policy is broken), I'm afraid we indeed do.

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.

I personally have plans to try to add plugins such as an EAR deployer, and plugins to wrap existing J2EE providers to go along with it (such as one for OpenEJB).

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 :-) ).

I think the answer is yes. Costin is proposing to develop a new loader underneath Catalina.
server.xml and Valves are Catalina components, so it is untouched. I had a long running plan to stop using the digester and rely on a JNDI layer to access the Catalina configuration. I don't know if I'll have time to do it, though (I prefer focusing on the new mapper for now, since the mapper currently used by Tomcat 5 is really bad).

Remy


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>