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
|