Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: softfail (athena.apache.org: transitioning domain of
 brian@pingtoo.com does not designate 217.154.193.216 as permitted sender)
Message-ID: <51E009F9.4010405@pingtoo.com>
Date: Fri, 12 Jul 2013 14:51:53 +0100
From: Brian Burch <brian@pingtoo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Puzzled by Access Valve Logging
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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