Logging filter (was RE: [next] What's next ?)

[joe user <pa...@yahoo.com>]

--- "Shapira, Yoav" <Yo...@mpi.com> wrote: 
> 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().

I'm not sure what would need to be changed in the
Filter implementation to allow these variables to be
exposed, but until they are, a Filter won't provide
enough information to the log users.  We definitely
definitely need to know response codes every time, for
example.

Either the Filter functionality needs to be changed,
or perhaps there should be a "Loglet" (ugh) API
specification so we can write logging classes in a
standard way.

This is a problem throughout Tomcat/Servlets: some
parts of the core functionality should be more
exposed.  For example, have you ever tried to write a
customer class loader for your webapp?  It is a mess. 
You need to subclass WebappClassLoader, which was
clearly never designed to be subclassed (and should be
marked "final" for that reason, according to Joshua
Bloch's book).  I still can't figure out how to tell
Jasper about using some different classloader.  All of
this is a mess and shouldn't be this way.

Sometime when I have more time maybe I will work on
these things.


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

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

Re: Logging filter (was RE: [next] What's next ?)

["Craig R. McClanahan" <cr...@apache.org>]

joe user wrote:

>--- "Shapira, Yoav" <Yo...@mpi.com> wrote: 
>  
>
>>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().
>  
>
Easily solved by having the filter add a response wrapper that provides 
access to the needed information.

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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org