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