[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