If you are feeling very brave. I submitted bug patch 12145:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12145
You can patch your tomcat to derive a new class with the same code as
provided by the patch.
This patch handles the problem discussed below in a different manner.
The patch allows the arbitrary writing of Session attributes,
ServletRequest attributes, specific incoming cookies, or incoming headers.
ex of usage:
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs" prefix="other_log." suffix=".txt"
pattern="%t \"%{cookie}i\" \"%{nelson}c\" \"%{jimbo}r\" \"%{kerny}s\" />
The above would spit out:
- the time
- The incoming cookie header
- The value of a cookie called nelson
- The value obtained by request.getAttribute("jimbo") OR
request.getAttribute("jimbo").toString()
- The value obtained by session.getAttribute("kerny") OR
session.getAttribute("kerny").toString()
Sessions are not created by asking for the session.
Guillermo Payet wrote:
> Hi Tim,
>
> What you propose sounds pretty technically elegant, but it
> also sounds like it would generate a lot of processing overhead,
> which is what I'm trying to avoid. (But maybe I'm wrong?)
>
> What I want is very simple application logging, with the least
> processing overhead possible associated to it. Having an
> AccessLogValve filtering every single request looking for an
> attribute meant for it is probably overkill. But then again,
> maybe I'm underestimating the way Catalina handles Valves?
>
> --G
>
>
> On Sun, Aug 25, 2002 at 02:12:14PM -0400, Tim Funk wrote:
>
>>My assumption is wish to log events/activities - not debug stuff
>>
>>This is not portable to other containers but you could do this. Declare
>>a common object name to go into your ServletRequest object ( like
>>event.login, event.logout) so when "things" occur you could have in your
>>code:
>>
>>request.setAttribute("event.login", whatever);
>>
>>
>>Then create a valve similar to the AccessLogValve which will pluck out
>>items in the ServletRequest object and write them to file.
>>
>>The tricky parts:
>>- defining log file format (columns defs, etc)
>>- what to call the stuff in the request object
>>- getting your developers to adhere to the conventions
>>- handling multivalue attributes and/or new attributes to log for
>>backwards compat.
>>
>>All the above are pretty easy. For max flex (but pain in parsing) is to
>>treat the log like a query string so you could have as many attribtues
>>as you want on one line.
>>EX:
>>{date} {ip} foo=bar&name=fred&answer=42
>>
>>To pick off the stuff left of the equals sign - you could say that is
>>the keys in the SerlvetRequest prefixed by "event." Then you could
>>iterate through the keys in SerlvetRequest object and look for anything
>>prefixed by "event." then write:
>>foo=fooValue where foo is part of "event.foo" and fooValue is the
>>attribute in the ServletRequest for "event.foo".
>>
>>To handle multi-values - you could check if the value implements
>>java.util.List -then write out foo=bar&foo=bar2,...
>>
>>
>>Seems pretty easy, but then again I'm pulling this out of thin air after
>>thinking about it for 30 seconds.
>>
>>Good luck.
>>
>>
>>-
>>
>>Guillermo Payet wrote:
>>
>>>Hi,
>>>
>>>I'd like to keep certain application logs as text files. Things like
>>>"search parameters used in a search form", or logs of "what users
>>>logged in or out and when".
>>>
>>>I'm wondering what's the simplest, most elegant, best performance way
>>>to do this. I was thinking about using Log4j for this, but it seems
>>>like overkill. Should I just create static PrintWriter(FileWriter),
>>>objects, and have my JSP pages and servlets write to those? Will this
>>>serialize writes effectively? Is there a better way?? Any ideas?
>>>
>>> thanks
>>>
>>> --G
>>>
>>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
