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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
