September 2013 - logback-user

Re: [logback-user] Logback suddenly stopped logging
by Andreas Dejung 19 Jun '14

19 Jun '14

I had the same problem and I think I know why J Solaris does interrupt IO blocked thread which then causes the OutputStreamAppender to catch the IOException in line 218 (version 0.9.24). I actually run version 0.9.18 but this part has not change so I guess it will behave the same way. If we look at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4385444 InterruptedIOException should not be required by platform specification (sol) And log4j https://issues.apache.org/bugzilla/show_bug.cgi?id=44157 InterruptedIOException ignored by log4j I think it should be solved the same why } catch (InterruptedIOException iioe){ //give the thread a changes to act on interruption and then carry on Thread.currentThread().interrupt(); } catch (IOException ioe) { // as soon as an exception occurs, move to non-started state // and add a single ErrorStatus to the SM. this.started = false; addStatus(new ErrorStatus("IO failure in appender", this, ioe)); } I could not find the jira entry mentioned in this thread therefore I write it here J BTY the jvm option -XX:-UseVMInterruptibleIO does prevent the interruption by solaris but that's only a workaround and not solving the problem ;) Cheers Andy

8 16

Re: [logback-user] Add header-lines to each log file
by Schoeftner, Thomas 20 May '14

20 May '14

Sorry to bump this topic again. Any ideas? Thanks, -Tom

3 2

Handling file access errors
by Gabriel Soto 01 Oct '13

01 Oct '13

Good afternoon, We are using Logback in a security sensitive application. The logging configuration normally includes a RollingFileAppender but we have the following requirement: If at any time a write to the log fails (due to a full disk, file permissions, etc.) the application must halt immediately, because no logs means no audit data, and that constitutes a high security risk. Now, the usual behavior when Logback can't write to the file is to log the error and continue. What would be the right way to handle this? Thank you, Gabriel

2 1

creating an OutputstreamAppender
by Michael Guymon 27 Sep '13

27 Sep '13

Hello Logbackers, I am trying to manually create an OutputstreamAppender that writes to a ByteArrayOutputStream. I am stumped by a NPE at LayoutWrappingEncoder.doEncode(LayoutWrappingEncoder). Here is a gist what I have so far[1]. From all the examples I found on the web, it appears correct. Sadly, it does not work. What I find odd is that I am passing in a PatternEncoder, so how is the LayoutWrappingEncoder being called? My understanding was LayoutWrappingEncoder was for deprecated Layouts. Any help would be greatly appreciated. 1: https://gist.github.com/mguymon/6723434 thanks, Michael

1 0

Logback/SLF4J and Akka
by Adam Gordon 24 Sep '13

24 Sep '13

Has anyone used Logback & SLF4J with Akka? We're seeing some really weird issues where log files aren't rolling when they're supposed to and the only thing that could be causing it is Akka because the log configuration by itself worked fine before Akka was introduced. We have the following Akka logging configuration set: # Log akka config settings akka.log-config-on-start=true # Event handlers to register at boot time (Logging$DefaultLogger logs to STDOUT) loggers = ["akka.event.slf4j.Slf4jLogger"] # Log level used by the configured loggers (see "event-handlers") as soon # as they have been started; before that, see "stdout-loglevel" # Options: ERROR, WARNING, INFO, DEBUG loglevel = INFO # Log level for the very basic logger activated during AkkaApplication startup # Options: ERROR, WARNING, INFO, DEBUG stdout-loglevel = INFO --adam http://gordonizer.com

1 0

NPE in Joran
by Franck Routier 24 Sep '13

24 Sep '13

Hi, we are hit by a NPE while configuring Logback. Here is the stacktrace: java.lang.NullPointerException at java.io.File.<init>(Unknown Source) at ch.qos.logback.core.joran.spi.ConfigurationWatchList.convertToFile(ConfigurationWatchList.java:88) at ch.qos.logback.core.joran.spi.ConfigurationWatchList.addAsFileToWatch(ConfigurationWatchList.java:52) at ch.qos.logback.core.joran.spi.ConfigurationWatchList.setMainURL(ConfigurationWatchList.java:48) at ch.qos.logback.core.joran.util.ConfigurationWatchListUtil.setMainWatchURL(ConfigurationWatchListUtil.java:46) at ch.qos.logback.core.joran.GenericConfigurator.informContextOfURLUsedForConfiguration(GenericConfigurator.java:92) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:48) at com.axege.core.init.AxabasContextListener.contextInitialized(AxabasContextListener.java:48) The code in AxabasContextListener looks like this: URL confFile = this.getClass().getResource(logContextFilePath); if (confFile != null) { LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); StatusManager statusManager = lc.getStatusManager(); OnConsoleStatusListener onConsoleListener = new OnConsoleStatusListener(); statusManager.add(onConsoleListener); try { JoranConfigurator configurator = new JoranConfigurator(); configurator.setContext(lc); // the context was probably already configured by default configuration rules lc.reset(); configurator.doConfigure(confFile); } catch (JoranException je) { je.printStackTrace(); } StatusPrinter.printInCaseOfErrorsOrWarnings(lc); } So we check if confFile exists, and it does, but we get a NPE in Joran... The very same code works on different environments, so this is probably due to the specific context we are deploying in, but we can't figure it out... Any help or pointer would be greatly appreciated. Regards, Franck

1 0

Formatting exceptions
by Russell Webb 24 Sep '13

24 Sep '13

I'm currently trying to configure logging for a Play app I'm working on so that the main part of the log messages are on one line. I reconfigured my file appender by removing the new lines except for at the end. <pattern>%date - [%level] - from %logger in %thread - %message - %exception%n</pattern> However when an exception occurs the message part appears two lines below the start of the log --- [error] application - ! @6fl7pl0b3 - Internal server error, for (GET) [/owner/4675002] -> - play.api.Application$$anon$1: Execution exception[[RuntimeException: Testing exception]] at play.api.Application$class.handleError(Application.scala:289) ... --- Does anyone know why this might happen and how I can change this? Thx

1 0

How to clear MDC values for specific thread once the operation is completed
by Govardhana 24 Sep '13

24 Sep '13

Hi, Recently we have upgraded our application from log4j to logback. we were successful to retain the existing functionality and added the unique features of logback. But... As our application is deployed in weblogic. it has thread-pool concept .. Due to this, we see that, when existing threads are being used for some operation, malicious data has been logged. we were tried to unset the MDC values explicitly by identifying the end point of application, still for some invocation, it became difficult to clear the MDC values.. Is there any way to clear the MDC values once the operation is completed? we have seen the below link,but not sure, whether it solves our issue or not.. http://jira.qos.ch/browse/LOGBACK-422 Any help is much appreciated. Regards, Govardhana Reddy -- View this message in context: http://logback.10977.n7.nabble.com/How-to-clear-MDC-values-for-specific-thr… Sent from the Users mailing list archive at Nabble.com.

3 2

OverlappingFileLockException when using common log among 2 tomcat contexts in same JVM.
by Christopher Holt 23 Sep '13

23 Sep '13

Hello, I have logback configured so that code bundled in 2 different war files under tomcat will write to the same log file which rolls daily. It's also marked as prudent. I believe my configuration follows the guidelines from ( http://logback.qos.ch/manual/appenders.html#prudentWithRolling) <configuration> <appender name="A1" class="ch.qos.logback.core.rolling.RollingFileAppender"> <prudent>true</prudent> <encoder> <pattern>%d{dd-MM HH:mm:ss} [%t] %c %5p %m%n</pattern> </encoder> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>${catalina.base}/logs/myapp.%d{yyyy-MM-dd}.log</FileNamePattern> <MaxHistory>30</MaxHistory> </rollingPolicy> </appender> <root level="INFO"> <appender-ref ref="A1"/> </root> </configuration> My problem is that I get lots of java.nio.channels.OverlappingFileLockException. ... java.nio.channels.FileChannel.lock(FileChannel.java:860) ch.qos.logback.core.FileAppender.safeWrite(FileAppender.java:187) ch.qos.logback.core.FileAppender.writeOut(FileAppender.java:204) ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:212) ... After reading the docs for OverlappingFileLockException, my hunch is that the 2 different loggers, loaded by different class loaders within the same JVM are both trying to lock the file, unbeknownst to each other. This violates the rules for FileChannel.lock, which seem to ignore the issue of locks among multiple class loaders within 1 JVM. Has anyone run into this issue before? Is there a simple workaround that I'm not thinking of? Thanks, Chris

4 4

Replacing Tomcat7 Logging with Logback?
by James Carr 17 Sep '13

17 Sep '13

Hi All, Is there a good tutorial or documentation on replacing Tomcat's default logging with logback? So far my searches turn up http://logback.qos.ch/access.html which only seems to work with access logs, not the actual server logging itself. Thanks, James

4 3