tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Claassen <>
Subject Re: AccessLogValve enhancement
Date Thu, 16 Feb 2012 21:06:20 GMT
I attached the two new valves in a zip file, ...not sure if this will come
through.  It was a pretty simple change.  Both valves seems to work pretty
well in my test cases, both using the standard mechanism and the original.

* (Potential performance, as mentioned previously)
* "common" pattern for AccessLogValve includes timestamp, which is also
often included in log record headers.
* header messages (#VERSION, #FIELDS:, #SOFTWARE) won't repeat in log
files, and are not
  necessarily useful in the initial one. (#FIELD is null, presumably
because its attribute was later in my server.xml file.)

Again, this would be an option that people wouldn't have to use.  I believe
it will work for me and is hopefully generally useful (otherwise it doesn't
make a good enhancement and is just clutter.)   Earlier, I was trying to
see how to do this by searching on the web and I found several others
asking the same thing.  So, I think there are many others who at least
think they want this feature.  :)


On Thu, Feb 16, 2012 at 10:17 AM, Mark Claassen <>wrote:

> Looking at the docs, it looks like the asynchronous parts of the logging
> mechanism are controlled through the logging configuration in either
> or  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 <
>> wrote:
>> 2012/2/16 Mark Claassen <>:
>> > 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:
>> For additional commands, e-mail:

View raw message