tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <r...@apache.org>
Subject Re: [next] What's next ?
Date Thu, 02 Oct 2003 15:08:01 GMT
Shapira, Yoav wrote:

> Howdy,
> On the subject of AccessLogValve: I hadn't thought of the things Tim
> suggested, but I have a different suggestion, part of a more general
> suggestion:
> 
> 1. Convert AccessLogValve to be a servlet specification 2.3 filter, i.e.
> something portable.  We can define it in $CATALINA_HOME/conf/web.xml,
> commented out by default perhaps, and users can move the definition
> around as they need just like they do with the servlets defined
> conf/web.xml.
> 
> Furthermore, people can then extend/customize AccessLogFilter much more
> easily, without needing to touch any tomcat classes.  And finally, this
> will allow the full power of filter-mapping to be applied to access
> logging. (I imagine the default in conf/web.xml would be the /*
> url-pattern mapping, but I know I and other users have different use
> cases).
> 
> If you think this is useful, I'd like to start working on it myself ;)
> If you think it's not useful/bad/stupid, please let me know ;)

Interesting. The pitfall is that optimizations could be harder, but 
otherwise, it could be a good idea. I think a significant amount of 
stuff did exist in TC 4.0 because of the fact that many things weren't 
there in the servlet API. A massive refactoring could be a good idea.

> 2. As an extension of the above idea, I would propose converting more of
> the tomcat non-standard features into portable implementations.  This
> includes the other filters, e.g. RemoteAddressFilter, RemoteHostFilter,
> RequestDumperValve, and others you think are appropriate.
> 
> 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.

Migration to commons-logging can IMO be restarted in 5.0, since the 
issues with commons-logging have been fixed. I think per instance 
loggers, with category names including the full component name, are needed.

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

I believe many people won't like that one. It's quite radical :) It is 
true that it would be much simpler to run only "straight" webapps, 
without exceptions.

I think this kind of classloading structure can be configured in TC 5 
using the catalina.properties.

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

So you want to do a HTTP load balancer ? I think this would be a really 
good project for the commons.

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

Is that useful ? I don't really see how. (ex: if you have no loader for 
a webapp, it won't work) I think you should elaborate more.

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

Let's see :)

Remy



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message