tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Logging request parameters - Filter vs Servlet
Date Wed, 30 Mar 2011 18:44:54 GMT
Hash: SHA1


On 3/30/2011 12:28 PM, Leo Donahue - PLANDEVX wrote:
>> -----Original Message-----
>> From: Christopher Schultz []
>> Subject: Re: Logging request parameters - Filter vs Servlet
>>> I don't know what I don't know... Log4j I guess.  That is what
>>> everyone recommends.
>> Hmm...
> ServletContext logging then?

The only logging the ServletContext will do is if you explicitly call
ServletContext.log(...) which Tomcat will direct to the appropriate
logger (set up using or, if you go through the
configuration, log4j).

>> There is an AccessLogValve that you can use if you know which request
>> parameters you want to log. There is also a RequestDumperValve (and
>> RequestDumperFilter in 7.0) that you can use to dump everything from the
>> request. See the docs for details.
>> Would those work for you?
> The AccessLog pattern I'm using:
> pattern="%h %l %u %t %r %q %s %b"
> The results:
> - - [29/Mar/2011:16:02:39 -0700] "POST /oppositioncase/oppositioncase.faces HTTP/1.1"
200 38621

Hmm... sorry to have steered you astray: looking at the documentation,
AccessLogValve only allows you to log request headers and attributes,
not parameters. That's a shame...

> My web app uses the JSF framework, forgot to mention that.
> samples:  
> 211-52-002A
> 211-74-016
> 211-53-005C

So you need to log the "txtAPN" parameter, right?

> Those are the parameters I'm trying to capture, along with the map image url.  
> A.  We'd like to know how many requests actually generated a map image.

Can you tell that, just from a parameter value? I would think that the
URL itself would more likely tell you if a map was generated.

> B.  We'd like to know whether this app is searching for parcels
> primarily in the unincorporated areas of the County, or parcels
> located within a city jurisdiction.  That part I can figure out once
> I know which parcels people are searching.

Simply logging the parcels used in searches would allow you to do that,
as you've said. The RequestDumperValve logs a /ton/ of information, and
probably wouldn't get you what you want.

>>> Note that reading request parameters in a Filter may trigger parsing of a POST
request body 
>>> which may not be something you want to happen on every request.
> I guess my only option then is to log them from the web app.  But
> somewhere I've read that is the wrong/lazy way to do logging.

I'm not sure where you read it, but that sounds like a platitude applied
as a blanket admonition not to log in your webapp. If it's appropriate
for your situation, then feel free to do it.

Back to the original "filter" question: logging using a filter is
perfectly acceptable if it's the right solution (see below for questions
that might lead you to other options). Writing the filter is trivial:
just implement the javax.servlet.Filter interface and be sure to read
the javadoc for it before you try: you'll thank yourself, later.

You can even use ServletContext.log() to write to the context log if you
want. Otherwise, feel free to use your webapp's log4j or other logging
facility (you'll have to configure this yourself). Just don't use
System.out :)

One might argue that blindly logging request parameters is not
particularly useful. For instance, a quick look at your interface
indicates that you can add several plots of land before performing the
search. Those initial "add" operations may be of little use to you.
Instead, you may wish to log them only at a certain point in your
workflow. Since most requests go to "oppositioncase.faces", you may not
be able to map your Filter to a URL pattern that is fine-grained enough.
Instead, it might make more sense to log this data when you know there's
a reason to log it. Since you're expecting to perform statistical
analysis on the data, you might even consider writing it directly to a
database instead of to a plain-old log file.

Cool webapp, by the way!

NB: The "ctrl" key isn't always the modifier key to use to de-select
items from a multi-select list. I think that's a Microsoft Windows
convention, but it's CMD-click on Mac and probably something like
META-click on *NIX.

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message