Trouble setting up logback in tomcat.
For my current project I would like to switch out all the logging which is currently being done by log4j and here en there by commons-logging to one framework. After some searching I discoverd SLF4J and Logback as the successor to log4j. In your code I swapped out all the log4j and commons-logging to the SLF4J api and I want to use Logback as my logger. I converted our log4j.properties file with the configuration converter on the website, so I assume that is correct. In the tomcat directory I have the following logging libs (I want tomcat to use SLF4J to) commons/lib/commons-logging-1.1.jar commons/lib/jcl104-over-slf4j-1.1.0-RC1.jar commons/classes/logback.xml In our webapplication (which is a packaged war and doesn't get unpacked!) I have WEB-INF/lib/slf4j-api-1.1.0-RC1.jar WEB-INF/lib/logback-classic-0.7.jar WEB-INF/lib/logback-core-0.7.jar WEB-INF/classes/logback.xml The contents of the logback.xml in the commons directory just contains a simple ConsoleAppender and is configured to WARN level. The file in the WEB-INF directory is configured as a file which should be written to c:\logs\mylog.log, configured different levels for different packages we use. However logback isn't getting picked up, everything is being logged by the java.util classes (as it appears thatone is being initialized by tomcat instead of the logback logger). I tried different configurations, all the logback/slf4j jars in the commons/lib and one config file in commons/classes. Different jars in commons/lib and WEB-INF/lib but until now everytime with the same result, only logging to JUL and nothing to logback and my configured logfile. Currently I'm at a loss on what to do and how to make it work. I need some assistance with this. Kind Regards, Marten -- View this message in context: http://www.nabble.com/Trouble-setting-up-logback-in-tomcat.-tf2858698.html#a... Sent from the Logback User mailing list archive at Nabble.com.
Hi Marten, Thanks for using logback :) Your web-app seems to be configured fine. Under Tomcat, or Jetty, it is sufficient to put the classic, core and slf4j-api jars in WEB-INF/lib and a configuration file in WEB-INF/classes. I've just tried with a fresh installation of Tomcat 5.5.20, and it went well. For this test, I didn't touch any configuration or jars in the Tomcat directory, I only added to the webapps directory the following files: in demo.war: WEB-INF/classes/logback.xml WEB-INF/lib/logback-classic-0.7.1.jar WEB-INF/lib/logback-core-0.7.1.jar WEB-INF/lib/slf4j-api-1.1.0-RC1.jar With this setup, my demo app logs to a given file, and Tomcat logs as usual. I suggest that you try this setup, without any attempt to intercept Tomcat's internal logging for now. If you want Tomcat to use SLF4J instead of commons-logging, it's a bit more complicated. Placing jars in the $TOMCAT_HOME/commons/lib/ directory will share logback's jars between web-applications, but will not make it available to the server. To influence Tomcat's behaviour, you have to put the jars in $TOMCAT_HOME/bin/ and add them to the server's classpath by editing the file catalina.sh if you're using startup.sh to launch Tomcat, otherwice edit catalina.bat. Using logback as the implementation used by both tomcat *and* all web-apps running under the server is not something that I have tested until now. I'll test that more deeply and keep you informed. Sébastien Marten Deinum wrote:
For my current project I would like to switch out all the logging which is currently being done by log4j and here en there by commons-logging to one framework. After some searching I discoverd SLF4J and Logback as the successor to log4j. In your code I swapped out all the log4j and commons-logging to the SLF4J api and I want to use Logback as my logger. I converted our log4j.properties file with the configuration converter on the website, so I assume that is correct.
In the tomcat directory I have the following logging libs (I want tomcat to use SLF4J to) commons/lib/commons-logging-1.1.jar commons/lib/jcl104-over-slf4j-1.1.0-RC1.jar commons/classes/logback.xml
In our webapplication (which is a packaged war and doesn't get unpacked!) I have WEB-INF/lib/slf4j-api-1.1.0-RC1.jar WEB-INF/lib/logback-classic-0.7.jar WEB-INF/lib/logback-core-0.7.jar WEB-INF/classes/logback.xml
The contents of the logback.xml in the commons directory just contains a simple ConsoleAppender and is configured to WARN level.
The file in the WEB-INF directory is configured as a file which should be written to c:\logs\mylog.log, configured different levels for different packages we use.
However logback isn't getting picked up, everything is being logged by the java.util classes (as it appears thatone is being initialized by tomcat instead of the logback logger).
I tried different configurations, all the logback/slf4j jars in the commons/lib and one config file in commons/classes. Different jars in commons/lib and WEB-INF/lib but until now everytime with the same result, only logging to JUL and nothing to logback and my configured logfile.
Currently I'm at a loss on what to do and how to make it work. I need some assistance with this.
Kind Regards, Marten
-- Sébastien Pennec sebastien@qos.ch Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch/
Hello Marten, I read your email again and would like to clarify a few more points about my previous answer... The information I gave you should allow you to configure and use logback as your logging implementation, for your application. I've seen that you put commons-logging-1.1.jar *and* jcl104-over-slf4j-1.1.0-RC1.jar in commons/lib directory. This will probably lead to unexpected behaviour, no matter how it is used. These two jars contains the same classes, up to a certain extent. jcl104-over-slf4j.jar is used to intercept calls to commons-logging and redirect them to a chosen SLF4J implementation. Having both commons-logging-1.1.jar and jcl104-over-slf4j.jar in the same classpath will provide you with two implementations of the same classes: one that redirects to SLF4J and the usual commons-logging implementation. If your application uses logback, but some other application that runs under Tomcat (or any dependency of your application) uses commons-logging, your might use jcl104-over-slf4j.jar to intercept these calls and redirect them to any SLF4J implementation. On the other hand, intercepting Tomcat's own *internal* logging is something that we do not recommand at this time. Sébastien Marten Deinum wrote:
For my current project I would like to switch out all the logging which is currently being done by log4j and here en there by commons-logging to one framework. After some searching I discoverd SLF4J and Logback as the successor to log4j. In your code I swapped out all the log4j and commons-logging to the SLF4J api and I want to use Logback as my logger. I converted our log4j.properties file with the configuration converter on the website, so I assume that is correct.
In the tomcat directory I have the following logging libs (I want tomcat to use SLF4J to) commons/lib/commons-logging-1.1.jar commons/lib/jcl104-over-slf4j-1.1.0-RC1.jar commons/classes/logback.xml
In our webapplication (which is a packaged war and doesn't get unpacked!) I have WEB-INF/lib/slf4j-api-1.1.0-RC1.jar WEB-INF/lib/logback-classic-0.7.jar WEB-INF/lib/logback-core-0.7.jar WEB-INF/classes/logback.xml
The contents of the logback.xml in the commons directory just contains a simple ConsoleAppender and is configured to WARN level.
The file in the WEB-INF directory is configured as a file which should be written to c:\logs\mylog.log, configured different levels for different packages we use.
However logback isn't getting picked up, everything is being logged by the java.util classes (as it appears thatone is being initialized by tomcat instead of the logback logger).
I tried different configurations, all the logback/slf4j jars in the commons/lib and one config file in commons/classes. Different jars in commons/lib and WEB-INF/lib but until now everytime with the same result, only logging to JUL and nothing to logback and my configured logfile.
Currently I'm at a loss on what to do and how to make it work. I need some assistance with this.
Kind Regards, Marten
-- Sébastien Pennec sebastien@qos.ch Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch/
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. Thanks again, kind regards, Marten -- View this message in context: http://www.nabble.com/Trouble-setting-up-logback-in-tomcat.-tf2858698.html#a... Sent from the Logback User mailing list archive at Nabble.com.
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/
By the way, Marten, You have not subscribed to the user mailing list, so I have to manually accept your emails to the list... you might want to subscribe to the list[1], so that you automatically recieve answers to your questions and see easily what others are discussing about logback :) Cheers, Sébastien [1]http://qos.ch/mailman/listinfo/logback-user
Sébastien Pennec wrote:
By the way, Marten,
You have not subscribed to the user mailing list, so I have to manually accept your emails to the list... you might want to subscribe to the list[1], so that you automatically recieve answers to your questions and see easily what others are discussing about logback :)
I should, however I'm using more mailinglist, and I would get flooded with mails from mailinglists. Which in turn my provided/boss doesn't like really. So I tend to read most of them thru Nabble or another frontend. Regards, Marten -- View this message in context: http://www.nabble.com/Trouble-setting-up-logback-in-tomcat.-tf2858698.html#a... Sent from the Logback User mailing list archive at Nabble.com.
Hello Marten, I suggest you give the following config file a try: <configuration debug="true"> <appender name="efx" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${catalina.home}/logs/efx.log</File> <Append>false</Append> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${catalina.home}/logs/efx.%d{yyyy-MM-dd}.log</fileNamePattern> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <pattern>%d %-5p [%logger] %msg%n</pattern> </layout> </appender> <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender"> <layout class="ch.qos.logback.classic.PatternLayout"> <pattern>%d %-5p [%logger] %msg%n</pattern> </layout> </appender> <!-- Performance interceptor --> <logger name="org.springframework.aop.interceptor.PerformanceMonitorInterceptor"> <level value="DEBUG"/> </logger> <!-- Logging for framework components. --> <logger name="org.springframework"> <level value="DEBUG"/> </logger> <logger name="org.springframework.webflow"> <level value="DEBUG"/> </logger> <logger name="httpclient.wire"> <level value="WARN"/> </logger> <logger name="org.codehaus.xfire"> <level value="WARN"/> </logger> <logger name="net.sf.ehcache"> <level value="WARN"/> </logger> <logger name="org.apache"> <level value="WARN"/> </logger> <logger name="org.acegisecurity"> <level value="INFO"/> </logger> <logger name="org.quartz"> <level value="WARN"/> </logger> <logger name="org.hibernate"> <level value="WARN"/> </logger> <root> <level value="INFO"/> <appender-ref ref="efx"/> <appender-ref ref="stdout"/> </root> </configuration> Compared to your config file, the above file 1) does not have <appender-ref> elements within <logger> definitions. 2) has the threshold option for the "efx" appender the removed (logback does not support thresholds although it supports filters) 3) the options for "efx" are listed before <rollingPolicy> element 4) the the <fileNamePattern> element contains "${catalina.home}/logs/efx.%d{yyyy-MM-dd}.log" instead of just yyyy-MM-dd Hope this helps, At 04:32 PM 12/20/2006, you wrote:
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/ _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Ceki, Thanks that did the trick. I also needed to supplie a commons-loggins.property file, to get the jcl104-slf4j.jar loaded in my web app. Thanks. Regards, Marten -- View this message in context: http://www.nabble.com/Trouble-setting-up-logback-in-tomcat.-tf2858698.html#a... Sent from the Logback User mailing list archive at Nabble.com.
participants (3)
-
Ceki Gülcü -
Marten Deinum -
Sebastien Pennec