If I am correct - your Valve code will not run until the request has
been already served to the client. So the client should not be affected.
by any delay. The only overhead is the added CPU to perform the logging.
Which is the price to pay for doing the logging.
Iterating through an Enumeration (request.getAttributeNames()) and
performing a String.startsWith() should be pretty fast since everything
is already in memory. (Unless LOTS of things are stored in the
ServletRequest object). The writing to disk will probably be the
bottleneck - which can be alleviated by using buffers and another (low
priority) thread to write to disk. (Classic producer-consumer problem
with many producers/one consumer)
-Tim
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]>
