[logback-user] Trouble setting up logback in tomcat.

Sebastien Pennec sebastien at qos.ch
Wed Dec 20 16:32:11 CET 2006


Hello Marten,

I've checked your configuration file, and it is almost ok.
When configuring a RollingFileAppender, one option that needs to be given is
the fileNamePattern. It is used to know how to rename files after the rollover has 
occured.

Your configuration files does contain the element, but its value was incorrect, here 
is something that you might use:

<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
   <param name="fileNamePattern" value="efx%d{yyyy-MM-dd}" />
</rollingPolicy>

The absence of the %d{} around the date pattern is something that could cause logback 
not to configure itself correctly. It is something that is pretty different from 
log4j, which uses elements like:

log4j.appender.R.datePattern=.yyyy-MM-dd

without %d{} around the date pattern.

Our properties translator webapp actually translates correctly many different log4j 
configurations, but cannot inspect the values that the user choose to correct them... 
yet. :)

When configuring logback, you might try to add an attribute to the configuration 
element like this:

<configuration debug="true">
...
</configuration>

It will ouput the statuses of logback after it has configured itself from your 
configuration file. Status objects are a part of logback's powerful error reporting 
framework. It allows users to see what's going on in logback. By using the debug 
attribute, you would have seen this in the console:

|-ERROR in ch.qos.logback.core.joran.spi.Interpreter at 544ec1 - Exception in Action for 
tag [rollingPolicy] java.lang.IllegalStateException: FileNamePattern [yyyy-MM-dd] 
does not contain a valid DateToken

Hope this helps,

Sébastien



Marten Deinum wrote:
> Hello Sébastien,
> 
> Thanks for taking the time to respond.
> 
> 
> Sébastien Pennec wrote:
>> I've seen that you put commons-logging-1.1.jar *and*
>> jcl104-over-slf4j-1.1.0-RC1.jar 
>> in commons/lib directory.
>> ...
>> On the other hand, intercepting Tomcat's own *internal* logging is
>> something that we 
>> do not recommand at this time.
>>
> That was one of the many feeble attemps to get logging working for our
> application, however I already removed them and now have just the logging
> tomcat provides (for tomcat that is). So no tomcat logging is going thru
> slf4j at the moment.
> 
> 
> Sébastien Pennec wrote:
>> The information I gave you should allow you to configure and use logback
>> as your 
>> logging implementation, for your application.
>>
> I tried it with the jars and configuration you mentioned, however I still
> have no logging :-(.
> 
> Currently I have the following logging jars and configuration
> 
> WEB-INF/lib/slf4j-api-1.1.0-RC1.jar
> WEB-INF/lib/logback-core-0.7.1.jar
> WEB-INF/lib/logback-classic-0.7.1.jar
> WEB-INF/lib/jcl104-over-slf4j-1.1.0-RC1.jar (we use some libraries in our
> web-app which use/require commons-logging)
> WEB-INF/classes/logback.xml
> 
> Here is the contents of my  http://www.nabble.com/file/4968/logback.xml
> logback.xml  file. It might be a configuration issue then? The configuration
> you see is the one generated (almost) with the configuration tool on the
> logback website. In the config I intentionally set the org.springframework
> logging to debug, it generates lots of debugging output, but alas I see
> none, not even a file is generated.
> 
> Thanks again, kind regards,
>  Marten

-- 
Sébastien Pennec
sebastien at qos.ch

Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch/



More information about the Logback-user mailing list