Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Logging filter (was RE: [next] What's next ?)
Date: Thu, 2 Oct 2003 15:39:24 -0400
Message-ID: <9C5166762F311146951505C6790A9CF83464B2@US-VS1.corp.mpi.com>
Thread-Topic: Logging filter (was RE: [next] What's next ?)
Thread-Index: AcOJB9aPg8Tasse4SsitzoTu/wiatQAE2ofA
From: "Shapira, Yoav" <Yoav.Shapira@mpi.com>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>


Howdy,
Thanks for the response wrapper idea and skeleton -- that seems to sol=
ve
most of the problems we discussed.

>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).

This is a problem.  I also think until servlet spec 2.4, filters don't=

see requests from request dispatchers, right?

How can we get around this, if at all possible, with a portable filter=
?

>* Filters only see the requests for their particular webapp.

It also just occurred to me that a legitimate, common use-case of thes=
e
access logs is for broken link analysis.  Having the filter just for t=
he
webapp would miss out on all requests outside the webapp like you say.=

Even if there's only one webapp installed on the server, you'd still
miss out on broken links.

>* Filters require the webapp to be configured itself to enable them,
>  versus the current approach where access logging is a container
>  configuration issue.

True, and there's the role separation idea between developer deliverin=
g
the webapp and deployer/sysadmin controlling the server.  The current
Valve implementation nicely separates those human roles, which my Filt=
er
idea would kind of break...

Yoav Shapira


This e-mail, including any attachments, is a confidential business com=
munication, and may contain information that is confidential, propriet=
ary and/or privileged.  This e-mail is intended only for the individua=
l(s) to whom it is addressed, and may not be saved, copied, printed, d=
isclosed or used by anyone else.  If you are not the(an) intended reci=
pient, please immediately delete this e-mail from your computer system=
 and notify the sender.  Thank you.


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