--- "Shapira, Yoav" <[EMAIL PROTECTED]> wrote:Easily solved by having the filter add a response wrapper that provides access to the needed information.
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 ;)
That sounds wonderful and useful, but there are a few
problems here. Filters don't have access to all the
information that is needed to make a log entry the way
the AccessLogValve does it. Content length, response
code and content type variables may not be known when
the filter is processing, and (last time I checked)
there is no byte[] Response.getContentType() method. There is setContentType() but no getContentType().
There's a jakarta-commons sandbox package called "filters" that was originally designed to be a home for general purpose Filters like this. If you want to experiment with creating Filter implementations of some things that are currently Valves in Tomcat, that would be a good place to do it.
For access logging in particular, I'd be concerned about a couple of things:
* Filters don't see every request (for example, the authentication challenges when you're using BASIC authentication).
* Filters only see the requests for their particular webapp.
* Filters require the webapp to be configured itself to enable them, versus the current approach where access logging is a container configuration issue.
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
