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 <
ch...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
