tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <>
Subject Re: [] Progress
Date Thu, 15 Jul 2004 17:18:08 GMT
Remy Maucherat wrote:

> My updated TODO. So I'll do the deployer next, followed by trying to 
> optimize startup time.
> Then, there's tweaking.
> Filip, do you have time to refactor the clustering soon ? I think we 
> should tweak your farming feature as well, as it should likely be done 
> the way the manager servlet is (rather, will be) doing its stuff. The 
> idea is to have only one big entry point for deployments, rather than 
> have 20 different components calling various deploy methods (which is 
> impossible to maintain). I need to write some code and experiment, and 
> then I'll have a clearer view of what this refactoring will look like 
> (sorry, it's just a little too messy right now for me to enumerate the 
> list of changes).
> - Attempt to redo a bit the deployer:
>   * remove the CL code which is there to avoid JAR locking (or at least
> allow disabling this feature for non-Windows OSes); when enabling anti 
> locking
> code, move everything to a temp "deploy" folder where everything will be
> referenced from; controlled by a "development" flag on the Context to 
> allow
> disabling this on Windows

Just a note:

Please allow the anti-locking stuff to be skipped on Windows as well.  
[Some of us value performance over deployment convenience.]

>   * move processing of context.xml to StandardContext (at the expense of
> being able to specify the context class, which will move to an attribute
> on the Host), as I realize it is important to get context level
> configurability without adding too much complexity in the embedding
> application; this could also go in ContextConfig, but this should be 
> done in
> another event (START occurs too late)
> - Use the webapp CL as the main CL (without the locking tricks it is 
> likely
> faster than the regular CL)
> - Resolve DBCP -> Pool -> Collections dependency, using package renaming
> - Remove anything useless (spring cleaning time), such as configuration
> options, container listeners (to be replaced with JMX notifications where
> it matters), etc
> - clutering module refactoring, to extend the regular Catalina 
> objects, for
> easier future maintenance

> - Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX 
> and JMX
> remote, etc)

It would be good to get many of the changes listed above this last point 
available in 5.0.x and usable with JDK 1.4.2 and then branch to 5.1 and 
do 1.5-specific goodies.

> - Externalize configuration saving out of StandardServer
> - And the ongoing: allow all config/management through JMX (actually, we
> could consider going to a JMX config format)

Jess Holle

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

View raw message