tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cyrille Le Clerc <>
Subject Re: Proposal to contribute a SyslogAccessLogValve to the Tomcat project
Date Thu, 12 Dec 2013 11:40:42 GMT
Thanks for your support Brian :-)

Regarding the performances, I'm sure that a native
SyslogAccessLogValve will have much better performances than relying
on a logging framework:
* there will be less layers to go through
* we can eliminate any String or byte[] creation which to lower the
pressure on the garbage collector
* we can leverage the "org.apache.catalina.Valve#backgroundProcess()"
to efficiently refresh network resources and DNS resolutions

I would be happy to contribute such native syslog implementation in
Tomcat core, in Tomcat extras or as a separated open source library.
The only help I need is the split of the AccessLogValve to reuse the
formatting logic.


On Thu, Dec 12, 2013 at 11:42 AM, Brian Burch <> wrote:
> 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.
> Regards,
> Brian
>> 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:

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

View raw message