|Mark Claassen||Feb 15, 2012 1:23 pm|
|Mark Thomas||Feb 15, 2012 1:32 pm|
|Mark Claassen||Feb 15, 2012 1:55 pm|
|Konstantin Kolinko||Feb 15, 2012 2:06 pm|
|Mark Claassen||Feb 16, 2012 7:16 am|
|Mark Claassen||Feb 16, 2012 1:05 pm||.zip|
|Konstantin Kolinko||Feb 16, 2012 1:11 pm|
|Mark Claassen||Feb 16, 2012 1:44 pm|
|Filip Hanik - Dev Lists||Feb 17, 2012 7:22 am|
|Francis Galiegue||Feb 17, 2012 7:54 am|
|Filip Hanik - Dev Lists||Feb 17, 2012 8:04 am|
|Rainer Jung||Feb 17, 2012 8:13 am|
|Christopher Schultz||Feb 19, 2012 9:20 am|
|Mark Thomas||Feb 19, 2012 9:49 am|
|Mark Claassen||Feb 19, 2012 6:53 pm|
|Christopher Schultz||Feb 21, 2012 8:37 am|
|Mark Claassen||Feb 24, 2012 8:49 am|
|Mark Claassen||Mar 27, 2012 6:29 am|
|Konstantin Kolinko||Mar 27, 2012 6:46 am|
|Mark Claassen||Mar 27, 2012 8:16 am|
|Mark Claassen||Mar 29, 2012 9:51 am|
|Konstantin Kolinko||Mar 29, 2012 1:43 pm|
|Mark Claassen||Apr 11, 2012 11:09 am|
|Subject:||Re: AccessLogValve enhancement|
|From:||Mark Claassen (mark...@gmail.com)|
|Date:||Feb 24, 2012 8:49:16 am|
I haven't had too much time to work on this in the past week, but will try to take another crack at something the weekend. Thanks for all the comments. I will try to find a way that address these concerns, and does not get too big or complicated.
Another route to take, would be to just add more configuration options to the existing access logger (like how many versions to keep). This would directly solve my immediate problem. However, it seems the vibe is leaning a bit toward having an option to use the JULI logger.
On Tue, Feb 21, 2012 at 11:37 AM, Christopher Schultz < chr...@christopherschultz.net> wrote:
On 2/19/12 12:49 PM, Mark Thomas wrote:
On 19/02/2012 17:20, Christopher Schultz wrote:
Philosophically, I'm not really sure why the flexibility of a full-featured logging system (JULI, log4j, etc.) is required for access logging: there's not much opportunity to use all the features they provide (log level filtering, log-message aggregation to log files and log-file multiplexing/splitting). Access logs typically log one thing (accesses), log it all the time, and always write to the same log file.
I'm not adverse to the patch, I just don't really see a need for it.
I was coming from the "I'd rather not maintain a bunch of code to solve a problem that the logging frameworks have already solved (threading, roll-over, output to multiple destinations)" angle.
That's something I hadn't really thought about, honestly. It's one of the best reasons to use a logging framework IMO.
I'd like to see some performance metrics, though, since putting a fully-fledged logging framework in the middle here has a distinct possibility of slowing everything down (for every request, of course). I kind of like Konstantin's idea of building extension-points into the AccessLogValve to allow a particular implementation of the Valve to handle the physical logging aspects while the AccessLogValve itself takes care of actually generating and emitting the log messages. That way, users can get the best of both worlds.
You know me, always happy to delete some code from the Tomcat code base.
Multiple implementations certainly doesn't lead to that end, but we'll see how things shake out.
My main point is that it is something worthy of discussion. And that is what we are doing.