You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Brian Burch <br...@pingtoo.com> on 2013/07/12 15:51:53 UTC
Puzzled by Access Valve Logging
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.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Puzzled by Access Valve Logging
Posted by Brian Burch <br...@pingtoo.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Puzzled by Access Valve Logging
Posted by Konstantin Kolinko <kn...@gmail.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org