[logback-user] Some logback-access questions
mikew at bluenile.com
Tue Dec 20 22:31:32 CET 2011
Thanks for the info. Sounds like a plausible workaround for #2. I'll try it out if I set up Logback-access again, but for now I've gone back to using Tomcat's AccessLogValve because of the query string issue.
It also looks like you can't get the thread ID in the Logback access logs, which is another piece of critical info for me. Unlike logback-classic where it is for thread ID, the %t token in logback-access is for dates.
From: Marshall Pierce [mailto:marshall at mpierce.org]
Sent: Friday, December 16, 2011 11:32 PM
To: logback users list
Cc: Mike Wartes
Subject: Re: [logback-user] Some logback-access questions
On 12/16/2011 08:43 AM, Mike Wartes wrote:
> I've been trying out the logback-access module as a potential
> replacement for Tomcat's AccessLogValve. I've run into a couple of
> issues that I'm wondering if anyone can help with.
> 1.It doesn't look like logback-access has the ability to print the query
> string like the %q value of Tomcat's AccessLogValve does. Am I missing
> something, or are there any workarounds? Unfortunately this is actually
> a dealbreaker for me if I can't make it work, since I need to have query
> strings in my access logs.
> 2.This one isn't a dealbreaker, but I'd like to configure one access log
> per webapp in my Tomcat container instead of one access log for all
> webapps. My first thought was that it'd be simple enough to configure
> the LogbackValve under each webapp's Context instead of under the Host
> element like the documentation suggests. However, I got stuck because of
> the way the LogbackValve is looking up its configuration file. I can't
> put the logback-access file in the container's conf directory because I
> want separate configuration per webapp. I also can't specify a relative
> path to the right webapp's folder because it can be in different places
> in different environments (the webapp files might not be in the
> container's folder at all). If I could look the configuration file up on
> the classpath I think that'd be pretty ideal, but from what I can tell
> it doesn't seem like that's possible.
> Any suggestions? I'm loving logback-classic and was excited to see that
> there is a module for access logs as well, but for the time being I
> think I may have to go back to the AccessLogValve.
> Thanks in advance.
> Logback-user mailing list
> Logback-user at qos.ch
I don't know about (1) but as far as (2) goes, I also need to configure
things from the classpath. I'm running embedded Jetty so I'm using the
Jetty-specific RequestLogImpl from logback access. Here's the gist of
the workaround I used while I wait for 1.0.1's
RequestLogImpl#setResource to be released:
RequestLogImpl logbackRequestLog = new RequestLogImpl();
URL configFileUrl = getClass().getResource(...);
JoranConfigurator jc = new JoranConfigurator();
// hook up logbackRequestLog as needed
It looks like LogbackValve implements Context and is therefore
applicable for JoranConfigurator#setContext(), so the same approach may
work for you.
More information about the Logback-user