tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Burch <br...@pingtoo.com>
Subject Re: Puzzled by Access Valve Logging
Date Sat, 13 Jul 2013 06:20:32 GMT
On 13/07/13 00:10, Konstantin Kolinko wrote:
> 2013/7/12 Brian Burch <brian@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


Mime
View raw message