|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 16, 2012 7:16:51 am|
Looking at the docs, it looks like the asynchronous parts of the logging mechanism are controlled through the logging configuration in either logging.properties or log4j.properties. I don't see any way to ensure that this is the case or to check to make sure the output is not going to the console.
That being said, this is just an option, and would hopefully be acceptable in many situations. I have not done tests to see the performance difference. Perhaps a strongly worded warning in the documentation would be sufficient to ensure people are smart about this?
Unless someone thinks that this change is unacceptable, I will continue my efforts and see what happens with it.
On Wed, Feb 15, 2012 at 5:07 PM, Konstantin Kolinko <knst...@gmail.com>wrote:
2012/2/16 Mark Claassen <mark...@gmail.com>:
We would like to use the flexibility of the standard logging mechanism for the AccessLogValue. I could find no way to do this. Looking at the AccessLogValve code in Tomcat 7, it seems it would really would not be hard to add.
There already is standard logger in the AccessLogValve class, which is where error in the logger itself get routed. private static final Log log = LogFactory.getLog(AccessLogValve.class);
This still makes a lot of sense, and should probably be kept separate. What I would propose is that a new attribute be added, called maybe "systemLoggerName". If this is set, then the logger by that name would be used instead of the current hard-coded file logger. (Errors would still go to the statically defined Logger.)
I already tried this with the XML listed below and a slightly modified AccessLogValve and it seems to work perfectly. If this is something that would be considered a positive change, I would be happy to submit a patch and propose some documentation updates.
I am not exactly sure how this all works, especially since this is more of an enhancement rather than a bug fix. I sure there are guidelines for when in a release cycle these types of changes are appropriate.
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="log" prefix="localhost_access_log." systemLoggerName="mylogger" pattern="common" resolveHosts="false"/>
I would say that the performance requirements for the two are different. Access log should be fast and simple. The error log does not have to be as fast, as errors should be more rare.
The default JULI FileHandler is not suitable here. You have to configure buffers. You have to perform flushing. AccessLogValve wires to Tomcat's background processing, but IIRC you cann do flush via commons-logging wrapper. The only viable alternative here is AsyncFileHandler.
You should also make sure that the events wouldn't be printed to Console.
The ideas to extract some common code to elsewhere (e.g. time formatting cache) were spoken several times. They are feasible.
Regarding this "systemLoggerName" (or "logCategory" as I would name it) feature, I think it does not belong to the current AccessLogValve but you might plug it there after some refactoring.
Anyway I would like to see the whole picture, which includes the logging configuration that you would use with AccessLogValve.
Best regards, Konstantin Kolinko