- logback-user - mailman3.qos.ch

parameter { } substitution is not happening with our custom appender
by Bob DeRemer 22 Sep '10

22 Sep '10

Hi Logback community, We created a custom appender to send logging data to our own storage medium. It extends AppenderBase<ILoggingEvent> like the docs say, but for some reason, any logging statements where we use the logback parameter substitution (i.e. "message with parameter {}", param1), there is no substitution. We have our custom appender AND a FileAppender. The fileappender has the parameter substituted, but the custom one does not. If anyone has any suggestions, I would greatly appreciate. Thanks, Bob DeRemer Senior Director, Architecture and Development <http://www.burningskysoftware.com/> http://www.burningskysoftware.com O: 717.505.7923 M: 717.881.3986

2 2

NoSuchMethodException in sysoutslf4j.PrintStreamCoordinatorFactory
by Raccoonwao 22 Sep '10

22 Sep '10

When calling SysOutOverSLF4J.sendSystemOutAndErrToSLF4J(), it always complains about NoSuchMethodException for sun.misc.Launcher$AppClassLoader.addURL(java.net.URL) I wonder if it should be addAppURL(...) instead of addURL(...)?

1 0

Re: [logback-user] Antwort: Re: Logging depending on Class / Method
by 无所谓 21 Sep '10

21 Sep '10

what's your logback version? ------------------ Original ------------------ From: "marc.baumgartner"<marc.baumgartner(a)degussa-bank.de>; Date: Tue, Sep 21, 2010 02:38 PM To: "logback users list"<logback-user(a)qos.ch>; Subject: [logback-user] Antwort: Re: Logging depending on Class / Method Okay, I try to explain it again: I would like to setting up the loglevels not only for a package, but for a method of a class. I have no default way so it doesn't matter how to solve it. But it is important that I can configure this rules easy in the logback.xml. Of course multiple loggers would work, but I dont want to take hand on the existing code. How could this work with markers? I had a look into the turbo filter, and yes it works perfect. I have defined a class LoggingRule which contains the classname and functionname for the Filtering. It looks like this: <filter class="de.degussabank.logging.LoggingRuleFilter"> <loggingRule class="de.degussabank.logging.LoggingRule"> <clazz>D</clazz> <function>method1</function> <level>INFO</Level> </loggingRule> </filter> But the problem I how can I configure the TurboFilter easily? I expect a lot of different rules and don't want to blast my configuration file. First I thought that I could do something like include another configuration file but this only works for appenders etc. not for enclosed elements like a filter... Is my explanation comprehendible? Marc Von: Ralph Goers <rgoers(a)apache.org> An: logback users list <logback-user(a)qos.ch> Datum: 20.09.2010 19:12 Betreff: Re: [logback-user] Logging depending on Class / Method Gesendet von: logback-user-bounces(a)qos.ch You really didn't provide enough information on what you are trying to accomplish. What you are trying to do is filter what events are logged. You could accomplish that by using Markers, multiple loggers, or a configurable TurboFilter (the turbo filter can inspect the method name of the caller). Ralph On Sep 20, 2010, at 7:21 AM, marc.baumgartner(a)degussa-bank.de wrote: 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 _______________________________________________ Logback-user mailing list Logback-user(a)qos.ch http://qos.ch/mailman/listinfo/logback-user _______________________________________________ Logback-user mailing list Logback-user(a)qos.ch http://qos.ch/mailman/listinfo/logback-user

2 1

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