February 2009 - logback-user

Logging and test coverage
by Joern Huxhorn 25 Feb '09

25 Feb '09

Hi everybody. I was wondering if somebody has found a solution for the problem that logging - in general, not just using Logback - lowers the coverage of application code because code after if(logger.isDebugEnabled()) is either executed or not, but not both, by the tests. It would be necessary to execute every test-method twice: once logging ALL and once logging OFF. Ignoring cases like that is not the solution because it can actually happen that a bug is enclosed or caused by such an if scope. It once happened that a variable was initialized inside of a larger if(logger.isDebugEnabled()) by mistake. This resulted in a behavior where everything worked until the logging level of that class was raised from DEBUG to INFO - which was a little bit nasty because everything would work again after lowering the level to DEBUG to look what's wrong... :p Does anyone have a good idea (or even a solution) how to tackle that problem? Regards, Joern.

4 4

remote logging?
by Rusty Wright 24 Feb '09

24 Feb '09

I have a batch job that's a jar file with a class that has a main method and the jar is run by the unix cron daemon every day. It runs on a production server that I don't have access to; I have to go to our release management (aka production control) team and ask them to make a zip file of my batch job's log files when I need to look at them. I was wondering if I could make it log remotely, but the only other server that's always up and accessible to me and others is our web farm. But the web farm machines are locked down and the only port that's open that I could use is 80 (and 443), which would go to an existing tomcat of mine. I'm thinking that what I could use is the nonexistent HttpAppender. I searched the archives and saw someone else asking about that and it seemed like there wasn't much interest in creating an HttpAppender and concern about an HttpAppender slowing things down too much. Are there alternatives that I could use?

1 0

TRACE messages get through even at DEBUG Level
by Andy Ruch 24 Feb '09

24 Feb '09

Hello, I'm using SLF4J 1.5.6 and Logback 0.9.15. I'm wanting to reconfigure Logback in my code, but I think I've found a bug. I've copied the following code from the documentation for how to reconfigure Logback. // assume SLF4J is bound to logback in the current environment LoggerContext lc = ( LoggerContext ) LoggerFactory.getILoggerFactory(); try { JoranConfigurator configurator = new JoranConfigurator(); configurator.setContext( lc ); // the context was probably already configured by default configuration // rules lc.reset(); configurator.doConfigure( url ); } catch ( JoranException je ) { je.printStackTrace(); } StatusPrinter.printInCaseOfErrorsOrWarnings( lc ); This works fine, except for when my new root logger level is DEBUG. If that is the case, I receive trace messages also. I have tracked the issue down to ch.qos.logback.classic.Logger. When localLevelReset() is called, the effectiveLevelInt is set to DEBUG_INT = 10. If it is the root logger, the level is also set to DEBUG. When the logger is being reconfigured, setLevel() is called with newLevel = DEBUG. Because level == newLevel, nothing happens and the method returns. However, effectiveLevelInt is never being set to ch.qos.logback.classic.Level.DEBUG_INT = 10000. When a TRACE log message is then evaluated, it is sent through because the effectiveLevelInt is still 10, even though Level should be DEBUG. Am I configuring something incorrectly? Thanks, Andy

2 3

Logback with multi-module Maven project
by Brian Cribbs 20 Feb '09

20 Feb '09

I've got a Maven project that (currently) produces 5 war files from 7 Maven modules. Can I configure Logback in one war file and have it work for all of the war files? Thanks in advance, Brian

3 3

Release of logback version 0.9.15
by Ceki Gulcu 13 Feb '09

13 Feb '09

12th of February 2009 - Release of logback version 0.9.15 I am happy to announce the immediate availability of logback version 0.9.15. This release fixes several important bugs and brings new features such as a servlet for viewing status messages. Please refer to the the news page for precise details. http://logback.qos.ch/news.html You can download logback, including full source code, class files and documentation on our download page, shown below. http://logback.qos.ch/download.html You can receive logback related announcements by subscribing to the logback announce mailing list. To subscribe to logback-announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/logback-announce Enjoy. -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch

2 3

Logback with Tomcat and multiple web applications
by Ryan Cornia 12 Feb '09

12 Feb '09

I've been struggling with this in Log4J, and am wondering if it's possible in Logback. If I have tomcat, with several web applications, can I have one instance of the logback jars in Tomcat/lib, and one configuration file, but distinguish between applications via variable substitution and the pattern? We are logging to SYSLOG, so I would like the pattern to include the application name. I looked through the manual, and see you can use variable substitution for specifying different files, but does substitution work in the pattern field? Can the ContextJNDISelector use a configuration file outside of the war? Ideally I would have the logging configuration file in tomcat/conf or somewhere, and have all applications use the same one. Thanks for any help!

3 6

Re: [logback-user] Logback with Tomcat and multiple web applications
by Robert Elliot 11 Feb '09

11 Feb '09

Use a ServletContextListener to put the application name into the MDC (servletContext.getServletContextName()) when the app starts. Then you can configure filters to allow you to log different application to different places, and you can use the MDC in the log output. As a general rule a web app that isn't part of an EAR should be deployed on a standalone basis, so you shouldn't really be deploying your jars & config to Tomcat/lib - that's outside the servlet specification. I know it seems a little wasteful to have the same jars in every web-inf/lib directory, but it's not really taking up much space. ----- Original Message ----- From: "Ryan Cornia" <rcornia(a)myriad.com> To: logback-user(a)qos.ch Sent: Wednesday, 11 February, 2009 16:57:17 GMT +00:00 GMT Britain, Ireland, Portugal Subject: [logback-user] Logback with Tomcat and multiple web applications I've been struggling with this in Log4J, and am wondering if it's possible in Logback. If I have tomcat, with several web applications, can I have one instance of the logback jars in Tomcat/lib, and one configuration file, but distinguish between applications via variable substitution and the pattern? We are logging to SYSLOG, so I would like the pattern to include the application name. I looked through the manual, and see you can use variable substitution for specifying different files, but does substitution work in the pattern field? Can the ContextJNDISelector use a configuration file outside of the war? Ideally I would have the logging configuration file in tomcat/conf or somewhere, and have all applications use the same one. Thanks for any help! _______________________________________________ Logback-user mailing list Logback-user(a)qos.ch http://qos.ch/mailman/listinfo/logback-user

1 0

Flushing problem
by Harish Krishnaswamy 06 Feb '09

06 Feb '09

I have a weird problem in my multi-threaded application on Solaris but not on Windows XP. Basically I have a bunch of tasks that are executed by the ThreadPoolExecutor and when the last task is executed the ThreadPoolExecutor is required to run a shutdown task (Runnable) provided to the executor by the main thread. The problem is, the log messages from this shutdown task never get flushed to the log file but it sure gets executed. I even added the LoggerContext.stop() to no effect. I am completely baffled as to why it is not flushing, any pointers/ideas will be much appreciated. Thanks. System Spec ========== System = SunOS Node = jdcsj002 Release = 5.10 KernelID = Generic_137137-09 Machine = sun4u -Harish

2 4

FileNamePattern
by Neil Lott 04 Feb '09

04 Feb '09

Hi, I'm using a FileNamePattern with a FixedWindowPolicy: Here's my appender: <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>/usr/local/mystro/logs/MSAServer.log</file> <append>true</append> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <FileNamePattern>/usr/local/neil/logs/MSAServer.%i. %d{yyyyMMdd-HHmmss}.gz</FileNamePattern> <MinIndex>1</MinIndex> <MaxIndex>3</MaxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <MaxFileSize>1KB</MaxFileSize> </triggeringPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d{ISO8601} %-5level [%thread] \(%logger{0}.%M:%L \\) - %msg%n</Pattern> </layout> </appender> Here's the exception when the file rolls -- I had to alter the rollover method of FixedWindowPolicy in order to catch throwable to see what was going on: java.lang.IllegalArgumentException: Cannot convert 3 of typejava.lang.Integer at ch .qos .logback .core .rolling.helper.DateTokenConverter.convert(DateTokenConverter.java:60) at ch .qos .logback .core.rolling.helper.FileNamePattern.convert(FileNamePattern.java:202) at ch .qos .logback .core.rolling.helper.FileNamePattern.convertInt(FileNamePattern.java: 210) at ch .qos .logback .core .rolling .FixedWindowRollingPolicy.rollover(FixedWindowRollingPolicy.java:103) at ch .qos .logback .core.rolling.RollingFileAppender.rollover(RollingFileAppender.java:105) at ch .qos .logback .core.rolling.RollingFileAppender.subAppend(RollingFileAppender.java: 128) at ch.qos.logback.core.WriterAppender.append(WriterAppender.java:119) at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:79) at ch .qos .logback .core .spi .AppenderAttachableImpl .appendLoopOnAppenders(AppenderAttachableImpl.java:60) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java: 439) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java: 393) at ch.qos.logback.classic.Logger.info(Logger.java:597) at ch .qos .logback.classic.net.SimpleSocketServer.run(SimpleSocketServer.java:79) Is this an intentional restriction to make the file name pattern have %i first and then %d? Thanks, Neil

2 1

Local/Remote config management at runtime
by Paul G 04 Feb '09

04 Feb '09

We have a requirement that we would like to centrally manage logging configuration files and push these out to applications as and when needed. So my questions are. Is it possible to reconfigure using Joran at runtime rather than one at initialisation time, are there any potential side effects? It would be fairly simple to write some code to listen for JMS or on a port to receive a message which would receive a Logback configuration, but would would be the message format? A logback configuration xml file how do then then pass that into Joran? The sending on messages is no problem as we would just create our own appender or use something like JMS appender to centralise log data collection. Any ideas would be great? Cheers Paul -- View this message in context: http://www.nabble.com/Local-Remote-config-management-at-runtime-tp21745848p… Sent from the Logback User mailing list archive at Nabble.com.

2 2