tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From joe user <paleha...@yahoo.com>
Subject Logging filter (was RE: [next] What's next ?)
Date Thu, 02 Oct 2003 16:17:04 GMT

--- "Shapira, Yoav" <Yoav.Shapira@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


Mime
View raw message