tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Angus Mezick" <>
Subject RE: [next] What's next ?
Date Thu, 02 Oct 2003 14:41:42 GMT

> -----Original Message-----
> From: Shapira, Yoav [] 
> Sent: Thursday, October 02, 2003 9:56 AM
> To: Tomcat Developers List
> Subject: RE: [next] What's next ?
> Then I have other ideas, of varying degrees of radicality and I'm sure
> stupidity ;)  I'm proposing them for discussion, as I think 
> they're all
> interesting.
> 1. Logging: use commons-logging throughout.  Eliminate tomcat logger
> implementation classes (FileLogger, SystemErrLogger, SystemOutLogger).
> Eliminate catalina.out file, instead having swallowOutput=true always
> without option to change.  Default logging configuration should still
> rotate nightly.

+1 with reservations. If this happens please make sure you use your own
file name and not the
Default commons-logging file name.  I have been tripped up when using 2 
Third party libs and my own that all used the commons-logging default
file name.  Ick.

> 2. Eliminate the shared and common classloader repositories.  Unless
> these are required by the spec?  Force webapps to be self-contained by
> putting all their classes in WEB-INF/lib or WEB-INF/classes of their
> webapp.  Have the WEB-INF/clases -> WEB-INF/lib -> endorsed -> system
> classloader hierarchy, much simpler than current.

-1 Ugh!  No.  I love the current format.  I have full control of what
webapps are in use on my system and I don't wish to have to maintain the
build config that has each of my 5 web apps copy from a central
repository instead of just using commons.  I find the current solution
rather elegant because I can use it but am not forced to.

> 3. Provide a complete working configuration example for a cluster of
> tomcat servers with a front-end tomcat as well, i.e. a pure 
> tomcat-only
> solution.  We already have the jvmRoute mechanism, but I 
> think it needs
> more examples/documentation so that people start using it.

+1 A must have.  Might also want to think of adding a way to have a DB
be the cluster session store.  I currently do this and love it.

> 4. Have no default objects created at runtime.  That means no default
> session manager if one is not configured, no default context if one is
> not configured, etc.  Ship tomcat with an example server.xml 
> containing
> all the default settings, and nothing more.

+0  Would make people more aware of what is going on in the background.
I worry about the support headaches this might inflict on tomcat-users.

> Of course, I'm willing to help on all of the above if we decide to do
> any of them.  
> That should be enough to get some talk going ;)
Yup.  Should be fun.
> Yoav Shapira
> Millennium ChemInformatics

--Angus Mezick

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

View raw message