September 2010 - logback-user

Logging depending on Class / Method
by marc.baumgartner＠degussa-bank.de 21 Sep '10

21 Sep '10

Hi all, is there a possibility to log depending on the class or method? For example I have the following scenario: package a.b.c public Class D{ Logger logger = LoggerFactory.getLogger(D.class); public void method1(){ logger.info("method1"); } public void method2(){ logger.info("method2"); } } I look for something like this in logback configuration: <logger name="a.b.c.D#method1" level="INFO" /> <root level="WARN"> </root> After calling method1 and method2 I would expect only the log entry of method 2. Is this possible? Thanks & regards, Marc

3 3

Logback - Changing logging level from the command line
by Keith Long 20 Sep '10

20 Sep '10

I need to be able to capture debug logs while the app is running. Today I can do this via jconsole but I would like to do so without launching the GUI. Is it possible to change the logging level for logback during run time from the command line? Thanks in advance, Keith

2 1

HELP - RollingFileAppender not logging when created entirely in code
by Bob DeRemer 15 Sep '10

15 Sep '10

Hi Logback community, I hope the problem is operator error, but I can't seem to figure this out. My java webapp requirements are such that we need to programmatically create our logback logging components (i.e. no use of an XML configuration file at all). This means I am resetting the LoggerContext and programmatically creating a single PatternLayout along with a ConsoleAppender and 2 specific RollingFileAppenders - 1 for general application logging and 1 dedicated to security-related stuff. If I create these as FileAppenders, they work fine, but as soon as I try and create RollingFileAppenders, the files get created, but nothing is logged out. I've provided the code I'm using below. If you look at the createRollingFileAppender method, you will see that I'm creating the TimeBasedRollingPolicy as well. I believe it has something to do with how I'm building up the RollingFileAppender and the Policy. Any suggestions would be greatly appreciated! Thanks, Bob DeRemer Senior Director, Architecture and Development <http://www.burningskysoftware.com/> http://www.burningskysoftware.com O: 717.505.7923 M: 717.881.3986 ============================================================================ ========================================= public void initializeLoggerContext() throws IOException { // clear logging context LoggerContext loggerContext = (LoggerContext) LoggerFactory.getILoggerFactory(); loggerContext.reset(); // create standard layout pattern to be used by all appenders PatternLayout layout = new PatternLayout(); layout.setContext(loggerContext); layout.setPattern(LAYOUT_PATTERN); layout.start(); // create console appender ConsoleAppender<ILoggingEvent> consoleAppender = new ConsoleAppender<ILoggingEvent>(); consoleAppender.setContext(loggerContext); consoleAppender.setLayout(layout); consoleAppender.start(); // create application appender FileAppender<ILoggingEvent> applicationAppender = this.createFileAppender(loggerContext, layout, APPLICATION_LOG); applicationAppender.start(); // create security appender RollingFileAppender<ILoggingEvent> securityAppender = this.createRollingFileAppender(loggerContext, layout, SECURITY_LOG); securityAppender.start(); // create configuration appender RollingFileAppender<ILoggingEvent> configurationAppender = this.createRollingFileAppender(loggerContext, layout, CONFIGURATION_LOG); configurationAppender.start(); // configure top-level ROOT logger Logger rootLogger = (Logger)LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME); rootLogger.addAppender(consoleAppender); rootLogger.addAppender(applicationAppender); // configure special security logger Logger securityLogger = (Logger)LoggerFactory.getLogger(SECURITY_LOG); securityLogger.setAdditive(false); securityLogger.setLevel(Level.DEBUG); securityLogger.addAppender(securityAppender); // configure special configuration logger Logger configurationLogger = (Logger)LoggerFactory.getLogger(CONFIGURATION_LOG); configurationLogger.setAdditive(false); configurationLogger.setLevel(Level.DEBUG); configurationLogger.addAppender(configurationAppender); } private FileAppender<ILoggingEvent> createFileAppender(LoggerContext loggerContext, PatternLayout layout, String logName) throws IOException { FileAppender<ILoggingEvent> appender = new FileAppender<ILoggingEvent>(); // get logs directory from Application Context ApplicationContext appContext = ApplicationContext.getInstance(); String logsRoot = appContext.getLogsDirectory(); String logFile = this.getLogFilePath(logsRoot, logName); // create appender appender.setContext(loggerContext); appender.setName(logName); appender.setFile(logFile); appender.setAppend(true); appender.setLayout(layout); return appender; } private RollingFileAppender<ILoggingEvent> createRollingFileAppender(LoggerContext loggerContext, PatternLayout layout, String logName) throws IOException { // get logs directory from Application Context ApplicationContext appContext = ApplicationContext.getInstance(); String logsRoot = appContext.getLogsDirectory(); String logFile = this.getLogFilePath(logsRoot, logName); // create appender RollingFileAppender<ILoggingEvent> appender = new RollingFileAppender<ILoggingEvent>(); appender.setContext(loggerContext); appender.setName(logName); appender.setFile(logFile); appender.setAppend(true); appender.setLayout(layout); // create rollover policy TimeBasedRollingPolicy<ILoggingEvent> policy = new TimeBasedRollingPolicy<ILoggingEvent>(); policy.setContext(loggerContext); policy.setFileNamePattern(this.getArchiveFileNamePattern(logsRoot, logName)); // MUST set parent - linking appender to policy, or you get a NULL ptr exception when starting appender policy.setParent(appender); // associate policy with appender appender.setRollingPolicy(policy); return appender; }

2 2

Clustered environment + cluster switch
by Alex Vb 15 Sep '10

15 Sep '10

The setup is 2 windows servers that have a clustered disk whos ownership can be transferred from one server to the other. Each server is using logback with a rolling file appender in prudent mode to write to a file. Everything works great until you transfer the ownership of the disk. After that, whatever is written to the log file seems to go nowhere and much much worse: for some reason in some circumstances (which i have been able to replicate generally but not pin down accurately), after the cluster switch is done, calling a logger service will hang the thread indefinately. I think i have been able to track down the problem to the locking mechanism used by the safe write method, the lock() seems to hang forever. Somehow the file lock was kept in memory, a JVM reboot fixes the problem. Currently we log asynchronously (behind a JMS-like messaging system), so there is only one server writing to the log file at the same time (though impossible to say which one). Because of this I am thinking of writing a custom appender that: - opens & closes a fileoutputstream each time (performance is less of an issue) - does not lock the file because the servers are guaranteed to process serially Any thoughts on the matter?

1 0

Heck of a time changing name of log file/pausing appender
by gordon＠activecert.com 11 Sep '10

11 Sep '10

Hi Everyone, I'm new to Logback and SLF4J. Things were going smoothly until I had two requirements - Change from a static log file name to a dynamic one Pause the console appender I googled quite a bit and found code that it appeared should work, but it unfortunately did not. I'll try to keep code/xml inclusion short and to the point. If someone can guide me on the correct practice to follow, it would be great. Logback jars are version 0.9.24 and SLF4J is at 1.6. Relevant portion of logback.xml is: <configuration debug="false" scan="false" scanPeriod="60 seconds">     <timestamp key="bySecond" datePattern="yyyyMMdd'_'HH.mm.ss"/>   <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">  </appender>  <appender name="ROLLINGFILE_SYSTEM" class="ch.qos.logback.core.rolling.RollingFileAppender">  <File>${system.logfile.name}-${bySecond}.log</File>  </appender>  </configuration> Approaches tested for dynamic filename: 1) use SLF4J Logger and Jason Configurator, 2) use Logback Logger. 1) In the case below, the logback.xml file is processed, and a file is created with the name "system.logfile.name_IS_UNDEFINED..." as expected. I then execute the code below to change the name (I also delete the file originally created). The result is a file with the desired name is created - but no logging occurs, either to the console or the log file! If I *don't* execute the code to change the file name, logging occurs just fine. I've wasted a ton of time trying to work with this. But even if this code worked, I'd be out of luck, because use case #2 requires pasusing an appender, and for that, I need to use the Logback logger directly. So on two #2 - change the log file name and access appenders. import org.slf4j.LoggerFactory; import org.slf4j.Logger; public class Foo { private static Logger logger = LoggerFactory.getLogger(ExecWrapper.class); public static void main(String[] args) { // -- attempt to change log file anme LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); JoranConfigurator configurator = new JoranConfigurator(); String logFileName = "foo.bar"; lc.reset(); lc.putProperty("system.logfile.name", logFileName); configurator.setContext(lc); configurator.doConfigure("logback.xml"); logger.info("test message."); ...etc. 2) In this code, I'd expect to be able to access the appenders - and not even have to use Joran. But the appender is null, and even the iterator for appenders has no elements! I'm sorry, but it's so unbelievably frustrating - I think life would be easier with plain old Java logging than with working with this. If anyone has any thoughts... import org.slf4j.LoggerFactory; import ch.qos.logback.classic.Logger; public class Foo { private static Logger logger = (Logger) LoggerFactory.getLogger(ExecWrapper.class); public static void main(String[] args) { LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); RollingFileAppender<ILoggingEvent > fileAppender = (RollingFileAppender<ILoggingEvent >)logger.getAppender("ROLLINGFILE_SYSTEM"); if(fileAppender != null) { String logFileName = "foo.bar"; fileAppender.stop(); fileAppender.setFile(logFileName + ".log"); fileAppender.setContext(lc); fileAppender.start(); } Regards, Gordon

1 0

Use of Dbappender for logging application events
by Pradnya Gawade 09 Sep '10

09 Sep '10

Hi All, I am a newbie to logback and trying to use Dbappender to log application events information into the database. As I did not get to see any examples of how Dbappender can be used for this purpose, I just want to confirm if I am using it in a right way or not. Every time an event message will be logged into logging_event table, the related event details will be stored in logging_event_property table as key-value pairs. These two can be associated with event_id in both the tables. As the contents of MDC are stored into logging_event_property table, I have to put my event details in the MDC context before I log the event message and remove it from the MDC context after the event message logging is complete. I am not sure if it is the right use of MDC context. Also the properties stored in logback.xml (e.g I store directory for log files) are inserted into logging_event_property table every time I log any statement. I saw one issue posted related to this in the logback issue tracking system and it seems I cannot avoid storage of these properties in database every time. Unnecessary lot of duplicate rows get inserted with this information. Please suggest if I can make any improvements. Thanks in advance. - Pradnya

1 0

OOM on debug level with SLF4j + Logback
by Jeff Jensen 08 Sep '10

08 Sep '10

Midway through the development of a new app, our Integration/Functional tests began failing with OOM. -Xmx is set to 1024m, so there should be plenty of memory. Our Logback test configuration logs to console, text file, and Lilith file. I profiled with Visual VM and found nothing extraordinary (memory usage bounced around, expanded, GC'd, came close to the max). On a whim I changed the log level from DEBUG to INFO and the OOMs stopped; this really surprised us. A lot of logging was occurring so I then experimented with appenders, e.g. not using Lilith appender, but that had no effect. Only reducing the level had an effect. Has anyone experienced this too? Are their known issues or gotchas that we may be unknowingly doing with logging? Any advice on how to find root cause? We then removed a lot of debug messages (good to clean up some of the development leftover junk, but some could have proven useful). Running with DEBUG log level no longer fails with OOM. I started creating a small project to demonstrate this issue, but it seems will require "a lot of stuff" to mimic our ITs (using dbUnit). Just running some simple log messages out in a big loop didn't show much. The test appender snippets: <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36}: %msg%n</pattern> </encoder> </appender> <property name="baseLogFileName" value="${logback.file.path:-target/}${moduleName}-TEST" /> <appender name="FILE-LOG" class="ch.qos.logback.core.FileAppender"> <file>${baseLogFileName}.log</file> <append>false</append> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <pattern>%date %contextName [%thread] %-5level %-55logger{55} %mdc: %marker: %msg%n</pattern> </encoder> </appender> <appender name="FILE-LILITH" class="ch.qos.logback.core.FileAppender"> <file>${baseLogFileName}.lilith</file> <append>false</append> <encoder class="de.huxhorn.lilith.logback.encoder.ClassicLilithEncoder"> <IncludeCallerData>true</IncludeCallerData> </encoder> </appender> <appender name="SECURITY_FILE" class="ch.qos.logback.core.FileAppender"> <file>${logback.file.path:-target/}${moduleName}-security-TEST.log</file> <append>false</append> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <pattern>%date %contextName [%thread] %-5level %-55logger{55} %mdc: %marker: %msg%n</pattern> </encoder> </appender> Here are the versions and the Maven POM deps in use: <lilithVersion>0.9.39</lilithVersion> <logbackVersion>0.9.24</logbackVersion> <slf4jVersion>1.6.1</slf4jVersion> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>${slf4jVersion}</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>jcl-over-slf4j</artifactId> <version>${slf4jVersion}</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>${logbackVersion}</version> </dependency> <dependency> <groupId>de.huxhorn.lilith</groupId> <artifactId>de.huxhorn.lilith.logback.encoder.classic</artifactId> <version>${lilithVersion}</version> <scope>runtime</scope> </dependency> <dependency> <groupId>de.huxhorn.lilith</groupId> <artifactId>de.huxhorn.lilith.logback.appender.multiplex-classic</artifactId > <version>${lilithVersion}</version> <scope>runtime</scope> </dependency> <dependency> <groupId>de.huxhorn.lilith</groupId> <artifactId>de.huxhorn.lilith.logback.servlet</artifactId> <version>${lilithVersion}</version> <scope>runtime</scope> </dependency>

4 8

1.0 release date?
by Ari Meyer 07 Sep '10

07 Sep '10

Hi, We'd like to switch from log4j to logback, but can't use beta releases. logback has been in development for over 4 years now -- any idea when we'll see a 1.0 release? Thanks, Ari

6 14

No output received in eclipse plugin
by Joshua White 03 Sep '10

03 Sep '10

Hello, I am using the following: logback eclipse plugin ver 1.1.0 logback 0.9.24 In my log files I receive a message indicating the logback is sending output to port 4321: 11:08:48,791 |-INFO in ch.qos.logback.classic.joran.action.ConsolePluginAction - Sending LoggingEvents to the plugin using port 4321 I don't receive anything in the eclipse plugin which is listening to the same port. I saw an entry on stackoverflow from March indicating that the plugin expected logback version 0.9.9. Is this still an open issue or do I have another problem? Thanks, Joshua

1 0

TRACE vs. DEBUG
by oss＠mrab.de 02 Sep '10

02 Sep '10

Hi all, I'm using LOGBack for some months now figured out something strange with the log levels: In the Level class the int values for TRACE and DEBUG are different, but the Integers are both set to the int value of the DEBUG level. The filters in JaninoEventEvaluator use the Integers (which are equal) so "level==DEBUG" matches both DEBUG and TRACE messages. Here is some code from logback-classic (0.9.24) ch.qos.logback.classic.Level: ////////////////////////////////////////////////////////////////// public static final int DEBUG_INT = 10000; public static final int TRACE_INT = 5000; public static final Integer DEBUG_INTEGER = new Integer(DEBUG_INT); public static final Integer TRACE_INTEGER = new Integer(DEBUG_INT); ////////////////////////////////////////////////////////////////// Is that a feature or a copy and paste bug? Any information is appreciated. Cheers, Melchior

2 1