tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Donahue - PLANDEVX <>
Subject RE: Logging request parameters - Filter vs Servlet
Date Wed, 30 Mar 2011 19:36:05 GMT

Thanks for the feedback.. very much appreciated!

>-----Original Message-----
>From: Christopher Schultz []
>Subject: Re: Logging request parameters - Filter vs Servlet
>So you need to log the "txtAPN" parameter, right?

Yes.  Actually, the contents of the listbox... as you'll see below.

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

No, I couldn't tell that from a parameter value, which is why I knew I had to log from within
the webapp somewhere, but I didn't know whether logging should happen in a filter or at a
specific place in the model.  Or should I log in the "fascade" (pattern)?

I wanted the logs to capture the url so that I knew the model reached a point where it generated
an image.
Those images are only there for 20 min, so that url is already dead.

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

You are right.

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

I'm going this route for now:

FacesContext.getCurrentInstance().getExternalContext().log(the string buffer of the parcel
FacesContext.getCurrentInstance().getExternalContext().log(the map URL);


Mar 30, 2011 12:02:35 PM org.apache.catalina.core.ApplicationContext log
INFO: PARCEL = '125-27-089'
Mar 30, 2011 12:02:45 PM org.apache.catalina.core.ApplicationContext log
Mar 30, 2011 12:03:16 PM org.apache.catalina.core.ApplicationContext log
INFO: PARCEL = '125-27-089' OR PARCEL = '125-27-090' OR PARCEL = '125-27-091'
Mar 30, 2011 12:03:27 PM org.apache.catalina.core.ApplicationContext log

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

Sadly, my department wanted that blurb on there.  They forget stuff.

View raw message