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@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@qos.ch Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch/