tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Burch <>
Subject Re: Proposal to contribute a SyslogAccessLogValve to the Tomcat project
Date Thu, 12 Dec 2013 10:42:11 GMT
On 12/12/13 08:56, Cyrille Le Clerc wrote:
> Hello Christopher,
> Delegating to log4j/logback/java.util.logging could be an option but it
> would still greatly benefit of a refactoring to split the existing
> AccessLogValve into an AbstractAccessLogValve with the formatting logic and
> an AccessLogValve that would keep the logic to write in the file.

I raised the issue of the AccessLogValve(s) not using the tomcat logging 
framework earlier this year. (ref: "Puzzled by Access Valve Logging" on 
the dev list.) Konstantin Kolinko pointed out that I should have held 
the discussion on the users list instead, and also that there were 
performance reasons for leaving the existing logic alone...

> With this split, the <MyLoggingFramework>AccessLogValve would extend the
> AbstractAccessLogValve.

I was not convinced by Konstantin, but did not have the time to 
undertake any research. I /still/ have an item on my "todo" list to 
develop an AccessLogValve that uses the implementation-defined tomcat 
logging framework (which in my case is bound to log4j). Performance is 
not an issue for me, but consistency of logging is more important.

My first task was to split the logger class in exactly the way Cyrille 
proposes. My initial impression several months ago was that the file 
handling could be refactored into a separate class, which extended an 
abstract class that performed the formatting (thus preserving a common 
set of formatting definitions, and also preserving high performance for 
those installations that require it).

I am travelling at the moment, so haven't had time to review Cyrille's 
code. However, I thought it would be helpful to register my thoughts as 
quickly as possible.

I hope his proposal is evaluated in a positive light. It isn't high 
priority, but I think it represents a valuable step forward with code 
that hasn't changed much over several releases.



> Regarding the existing Syslog implementations in Log4j and Logback, they
> don't yet allow user to customise the syslog header fields but I plan to
> propose to contribute these enhancements.
> Finally, regarding the idea of injecting a logging framework jar in Tomcat
> classloader, I feel it makes things pretty difficult to understand with the
> risk of collision of the jars.
> As a conclusion, I would be very happy to contribute to the Tomcat project
> either the full SyslogAccessLogValve or just the split of the existing
> AccessLogValve into an AbstractAccessLogValve with the formatting logic and
> a AccessLogValve with the logic to write in files.
> Cyrille
> On Thu, Dec 12, 2013 at 3:58 AM, Christopher Schultz <
>> wrote:
>> Hash: SHA256
>> Cyrille,
>> On 12/11/13, 1:49 PM, Cyrille Le Clerc wrote:
>>> Dear Tomcat community,
>>> We at CloudBees implemented a SyslogAccessLogValve that outputs
>>> the access logs to a syslog server.
>>> The support of Syslog is more detailed that what we can usually
>>> find in java logging libraries as it allows to * configure all the
>>> syslog header fields: appName, source hostname, severity and
>>> facility * format syslog message according the RFC 3164 and to RFC
>>> 5424
>> Honestly, I think it would make more sense for the AccessLogValve to
>> be tied instead of directly to a file or syslog, to be tied instead to
>> a logging API. There already exist (relatively) standard syslog sinks
>> for log4j, java.util.logging, etc. Why create another one?
>> - -chris
>> Version: GnuPG v1.4.15 (Darwin)
>> Comment: GPGTools -
>> Comment: Using GnuPG with Thunderbird -
>> jAGlvkKssADw3h2vEQG2rerY7jG8YVBVe6sO1CCEBBfl/rjqxSireuWTqRI0Sc12
>> KPl/pYgiJQhvA1OqDvj2kZfoL4s59MVJSlN1A3ZTEs7wp1udWXN/k5tsumIKL2dE
>> 9/D+xDBBwbktVT8OXee6SmjGmCA3UeArVabEH67k6rPyA1koL7ScwVgTH+zbAj+b
>> yf/NusknEGv1Qm37jipVV16vpV9ZR0WEHrCghtfUYtKPsPVAphZzh+DjAZ3hGW+j
>> Do5m1DC/u/QOacJGMOcyrKOiMgfLV81C8x/y6M+5me0HSpYZIPKiOROgILqXyK+i
>> UjKBkABWkeKL9T/0IsHAqQdfD0w37xgTb6Fa6lgq39CRQc+rdn+DuUrrg8H0pDqs
>> T5bV8DXIXeyIYP0+5xpKuZJGmGdWYTiwzu15GexUBTFocfWj5A9BGN+dIm9q++hZ
>> Rf1rwLaMXkXzKPXVmml+rNAELsup4S1wgQKeptCueNsloBvftZqg06QpaIPJz5WF
>> 1aJhc4cn9or4oQMUs2Qcc7GnU6RV1pSycI8IyDpgqV/GBX0UPJibD1D99vet9JhF
>> PfOtGYrzffGC3bv9Ebo6qOHb2SH0zqCE/C4e1ImsrdLTvb3zqAKwwtsjn5y3f2Kl
>> CL48rzdXsU4lgV1IAijP
>> =K/kz
>> -----END PGP SIGNATURE-----
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message