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. Thanks, Mark On Wed, Feb 15, 2012 at 5:07 PM, Konstantin Kolinko <knst.koli...@gmail.com>wrote: > 2012/2/16 Mark Claassen <markclaass...@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. > > > > Mark > > > > > > <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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
