2013/7/12 Brian Burch <br...@pingtoo.com>: > While working on https://issues.apache.org/bugzilla/show_bug.cgi?id=55215, I > was surprised to discover my log files generated by AccessLogValve do not > seem to be handled by log4j. > > I've worked with the various Authenticator Valves and all I could remember > was they used the juli Logger services, which are now being handled by log4j > as I expect. > > Because I had forgotten to change server.xml, my entry still looks like > this: > > <Valve className="org.apache.catalina.valves.AccessLogValve" > directory="logs" > prefix="access." suffix=".txt" > pattern="common" resolveHosts="false"/> > > I checked docs/config/valve.html for guidance on using juli or log4j, but > couldn't find any clues. These, and other, logging-related parameters are > only documented for AccessLogValve and ExtendedAccessLogValve. > > I then looked at the source in tc8 trunk. At first glance, the class seems > implement a self-contained logging system, complete with daily roll-over > logic. > > I went back as far as the tc5 source in January 2007. There have been quite > a few changes, but the general idea hasn't changed significantly since then. > > In fact, the current tc8 source seems to me to use both juli and the > self-contained logging println service, e.g. > > /** > * Log the specified message to the log file, switching files if the > date > * has changed since the previous log call. > * > * @param message Message to be logged > */ > public void log(CharArrayWriter message) { > > rotate(); > > /* In case something external rotated the file instead */ > if (checkExists) { > synchronized (this) { > if (currentLogFile != null && !currentLogFile.exists()) { > try { > close(false); > } catch (Throwable e) { > ExceptionUtils.handleThrowable(e); > > log.info(sm.getString("accessLogValve.closeFail"), e); > } > > /* Make sure date is correct */ > dateStamp = fileDateFormatter.format( > new Date(System.currentTimeMillis())); > > open(); > } > } > } > > // Log this message > try { > synchronized(this) { > if (writer != null) { > message.writeTo(writer); > writer.println(""); > if (!buffered) { > writer.flush(); > } > } > } > } catch (IOException ioe) { > log.warn(sm.getString( > "accessLogValve.writeFail", message.toString()), ioe); > } > } > > > Am I being stupid? Have I overlooked something obvious? > > If not, does anyone have any historical information about this > implementation? My first thought is that this Valve should simply use juli > (or log4j via the juli adapter) throughout, just the way the other valves > already do. >
It is a different feature, with different requirements. The essential requirement for an access log is that it has to handle a large continuous stream of data with low overhead. Note the buffering and flushing. Wiring the above to an arbitrary logging system through Apache Commons Logging wrapper would just add several layers of overhead and complicate the configuration. A generic logging system has different requirements. It is used to log errors and warnings (which usually do not occur often). It needs highly configurable filtering and minimal overhead when logging is disabled. That is the essence. I think your question really belongs to the users@ list. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
