On 13/07/13 00:10, Konstantin Kolinko wrote:
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.
Thanks for your answer. I am a bit surprised the class-level comments do
not mention this issue, but I suppose that is because the class has been
around for such a long time.
That is the essence. I think your question really belongs to the users@ list.
I spent some time thinking about the best place to pose my question. I
chose the dev list because it was about the design of a specific part of
tc code which looked anomalous to me, and which might or might not
benefit from change.
I could not foresee your answer, which I agree makes the topic more
appropriate for the users list. Do you want to move the Q&A, possibly
with some editing?
I think this subject deserves mention in the log4j section of
logging.html, and probably also valve.html. Do you agree?
Thanks for taking the time to explain.
Brian
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
