You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2015/11/20 20:44:52 UTC

access log valve not using logger?

Hi guys,

any reason the AccessLogValve doesnt rely on JULI -
https://github.com/apache/tomcat/blob/trunk/java/org/apache/catalina/valves/AccessLogValve.java#L515
?

Makes it quite complicated to extend the logging logic or use another
logging framework with more rotation policy for instance.

Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: access log valve not using logger?

Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1, that is more or less what I just hacked for tomcat 7/8.

Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber


2015-11-20 12:01 GMT-08:00 Christopher Schultz <ch...@christopherschultz.net>:
> Romain,
>
> On 11/20/15 2:44 PM, Romain Manni-Bucau wrote:
>> any reason the AccessLogValve doesnt rely on JULI -
>> https://github.com/apache/tomcat/blob/trunk/java/org/apache/catalina/valves/AccessLogValve.java#L515
>> ?
>
> Because JULI is slow, and we want logging to be fast.
>
> Logging frameworks are super-flexible, let you add/remove information at
> runtime and do things like conditionally-log messages or even
> conditionally filter them as they are going to log sinks (like a
> specific file for instance). For an access log, you pretty much always
> want to log everything. There's no reason for all those options.
>
>> Makes it quite complicated to extend the logging logic or use another
>> logging framework with more rotation policy for instance.
>
> The rotation policy for the access logger is certainly crude.
>
> I don't believe AccessLogValve was really intended to be extensible...
> that's what AbstractAccessLogValve is for: just write your own subclass
> like this:
>
> public class FrameworkAccessLogValve extends AbstractAccessLogValve {
>   private Log log;
>   private Level level;
>   public void setLog(Log log) { this.log = log; }
>   public Log getLog() { return this.log; }
>   public void Level setLevel(Level level) { this.level = level; }
>   public Level getLevel() { return this.level; }
>
>   @Override
>   protected abstract void log(CharArrayWriter message) {
>     getLog().log(getLevel(), message);
>   }
> }
>
> If you think that kind of thing would be useful in Tomcat, I suppose we
> could commit it.
>
> -chris
>
> ---------------------------------------------------------------------
> 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: access log valve not using logger?

Posted by Christopher Schultz <ch...@christopherschultz.net>.
Romain,

On 11/20/15 2:44 PM, Romain Manni-Bucau wrote:
> any reason the AccessLogValve doesnt rely on JULI -
> https://github.com/apache/tomcat/blob/trunk/java/org/apache/catalina/valves/AccessLogValve.java#L515
> ?

Because JULI is slow, and we want logging to be fast.

Logging frameworks are super-flexible, let you add/remove information at
runtime and do things like conditionally-log messages or even
conditionally filter them as they are going to log sinks (like a
specific file for instance). For an access log, you pretty much always
want to log everything. There's no reason for all those options.

> Makes it quite complicated to extend the logging logic or use another
> logging framework with more rotation policy for instance.

The rotation policy for the access logger is certainly crude.

I don't believe AccessLogValve was really intended to be extensible...
that's what AbstractAccessLogValve is for: just write your own subclass
like this:

public class FrameworkAccessLogValve extends AbstractAccessLogValve {
  private Log log;
  private Level level;
  public void setLog(Log log) { this.log = log; }
  public Log getLog() { return this.log; }
  public void Level setLevel(Level level) { this.level = level; }
  public Level getLevel() { return this.level; }

  @Override
  protected abstract void log(CharArrayWriter message) {
    getLog().log(getLevel(), message);
  }
}

If you think that kind of thing would be useful in Tomcat, I suppose we
could commit it.

-chris

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org