[PROPOSAL][TOMCAT5] plugins directory

[Costin Manolache <cm...@yahoo.com>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [PROPOSAL][TOMCAT5] plugins directory

[Remy Maucherat <re...@apache.org>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [PROPOSAL][TOMCAT5] plugins directory

[Amy Roh <am...@apache.org>]

>> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [PROPOSAL][TOMCAT5] plugins directory

[Costin Manolache <cm...@yahoo.com>]

Sorry for the late reply, I had no mail for few days.

Jeanfrancois Arcand wrote:

>>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 agree.

Plugins should replace .jar files that are placed into server/lib and
common/lib - and the same mechansims would apply. 

Each plugin should be able to define what goes into server/lib loader,
what goes into common/lib loader, eventually and additional class loader
to keep it's implementation isolated. And also set options on the class
loaders - the module initialization ( in the mbean register callback )
can call tomcat APIs and set whatever it needs, register for hooks,
etc ( similar with apache2 modules init() ).


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

I think this is a special case, and we'll have to keep it separated.
Note that xerces itself is not a problem - the jaxp. classes are the
ones needing endorsed. We could leave xerces as a module and have
only xmlParserApis special.

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

By using WAR I meant reusing the current infrastructure and possibly the 
layout.( for example reloading plugins may be very interesting :-).
The standard manifest and the META-INF/services should be enough to identify
the services - but we will need mbeans.xml ( for modeler ) and probably
an mlet-style config to define the classloaders or options.

I agree we shouldn't add ( if possible ) any new xml dtd, there are more
then enough already :-) I think the existing ( standard or already used ) 
mlet, mbeans.xml, services provide all the meta info we need.


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

By defining the classloader - I meant more declarative definition.
The plugin can instantiate a tomcat mbean for the loader 
( we should have an mbean associated with the tomcat loader anyway ),
or just use the <classpath> in the mlet.

If the plugin decides to create its own loader - he probably
knows what it's doing, but I hope that won't happen too often.

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

We already have that. Modeler. Works very nice :-) 


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

My proposal has nothing to do with server.xml or Valves or any other hook
mechanism.

It's about layout ( plugins/ or modules/ ) and how the modules are 
registered in tomcat ( using Mbean registration and nothing else ).
How the modules are deployed ( using a dowload target or a full distribution
and a command to remove some or anything else ) is also a separate issue.

In general - I think server.xml should work ( backward compat at least),
but we should also work on a different config file that is more friendly
to editing and JMX config. I preffer using mlet-like style - it is very 
simple, standard ( or slightly extended :-), easy to generate. 


Costin



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [PROPOSAL][TOMCAT5] plugins directory

[Jeanfrancois Arcand <jf...@apache.org>]

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.

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:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>  
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [PROPOSAL][TOMCAT5] plugins directory

[Costin Manolache <cm...@yahoo.com>]

Remy Maucherat wrote:

>> 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.
> 
> +1.
> 
> #7: The configuration mechanism I added should be replaced by that.
> #8: I think you need some kind of configuration file (or rather,
> resource) though ;-)


If by resource you mean some .xml in the jar with the defaults - yes.
But it should work as a single jar ( or collection of jars ) you 
just include in a product ( or in ant/lib ) and then create one
mbean and start it ( maybe set the port and some options first -
if you don't like the defaults ).

BTW - I don't know if anyone noticed the <mbean> ant tasks 
( that I added to modeler ) and the last part of catalina.xml
ant buildfile, it's a small example.

Costin 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [PROPOSAL][TOMCAT5] plugins directory

[Remy Maucherat <re...@apache.org>]

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.  

+1.

#7: The configuration mechanism I added should be replaced by that.
#8: I think you need some kind of configuration file (or rather, 
resource) though ;-)

Remy


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [PROPOSAL][TOMCAT5] plugins directory

[Henri Gomez <hg...@apache.org>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>