tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cyrille Le Clerc <clecl...@cloudbees.com>
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.

Cyrille


On Thu, Dec 12, 2013 at 11:42 AM, Brian Burch <brian@pingtoo.com> 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 <
>> chris@christopherschultz.net> wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> 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
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.15 (Darwin)
>>> Comment: GPGTools - http://gpgtools.org
>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>
>>> iQIcBAEBCAAGBQJSqSZYAAoJEBzwKT+lPKRYQJ8P/jgRDOCvSLgjZsAkVT32fSOf
>>> 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: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message