September 2012 - 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

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

(Important) Dynamically change the scan period
by Yihya Hugirat 08 Apr '13

08 Apr '13

hi all, i have migrated to logback to be able to change the log levels dynamically. i'm testing it now with calssfish 3.01 and somehow it is not working when i change the levels in logback.xml there nothing happens. by deploying from netbeans i get the following: |-INFO in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@11bfee0 - Will scan for changes in [[C:\Dokumente und Einstellungen\user_Home\Eigene Dateien\NetBeansProjects\WS-LDAP\build\web\WEB-INF\classes\logback.xml]] every 15 seconds. but when i change the levels in this file nothing happens Any help will be appreciated Hugirat -- إِنَّ الَّذِينَ يُحِبُّونَ أَنْ تَشِيعَ الْفَاحِشَةُ فِي الَّذِينَ آمَنُوا لَهُمْ عَذَابٌ أَلِيمٌ فِي الدُّنْيَا وَالآخِرَةِ وَاللَّهُ يَعْلَمُ وَأَنْتُمْ لا تَعْلَمُونَ My public key please use it when you contact me: هذا مفتاحي العام الرجاء أستخدامه عند الإتصال بي: 09BA B710 4B98 ECDA 8C0A 6CB1 2E1E CF88 6A12 F2C3

3 4

Externalized Logback configuration for web applications
by Perryn Fowler 01 Feb '13

01 Feb '13

Hello, I have a logging use case that I would think was relatively common, but that does not seem to be supported particularly well by logback. I wanted to see what the logback community thinks/advises. The details of the use case - I am writing java web apps to be deployed to JEE web containers. - I want the logging config to be external to the wars, so that I can use the same wars in different environments, but configure logging differently. - I want to be able to deploy several different wars to the same web container and have them use different logging configurations. The logback documentation seems to push towards either packaging the logback config in the wars, or sharing an external logging config between them. (Whereas I want separate external logging configuration for each war) I hope that makes sense. The JNDI support described here: http://logback.qos.ch/manual/loggingSeparation.html looks like it might be of use, but it does seem to require that the config files are placed in WEB-INF/classes and I would prefer they are completely external to the war. I have found a number of people who have coded up their own solutions, notably: http://blog.iprofs.nl/tag/logback/ and https://bowerstudios.com/node/896 That doesn't look too bad, but wondering what the community thinks of these approaches -- ----------------------- Perryn Fowler

6 10

SMTPAppender, HTMLLayout with text/plain
by Filipe Sousa 14 Nov '12

14 Nov '12

Hi. For some reason I'm receiving email reports with mime type text/plain and my email client shows all the html code. I'm attaching a report sent by logback. I'm using javax.mail 1.4.4 and this logback (1.0.3) configuration <?xml version="1.0" encoding="UTF-8"?> <configuration scan="true" scanPeriod="5000"> <appender name="file" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>../logs/sama.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>logFile.%d{yyyy-MM-dd}.log</fileNamePattern> <maxHistory>30</maxHistory> </rollingPolicy> <encoder> <pattern>%d [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> </appender> <appender name="mail" class="ch.qos.logback.classic.net.SMTPAppender"> <smtpHost>mail.ipb.pt</smtpHost> <to>filipe(a)ipb.pt</to> <from>noreply(a)ipb.pt</from> <subject>[sama]: %logger{20} - %m</subject> <layout class="ch.qos.logback.classic.html.HTMLLayout" /> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter> </appender> <logger name="org.eclipse.jetty" level="WARN" /> <logger name="org.apache.cxf" level="WARN"/> <logger name="pt.ipb.sama" level="WARN" /> <root level="WARN"> <appender-ref ref="file" /> <appender-ref ref="mail"/> </root> </configuration> Thanks -- Filipe Sousa

2 1

java.net.UnknownHostException in ch.qos.logback.core.util.ContextUtil on startup
by Marshall Pierce 25 Sep '12

25 Sep '12

I get the following (and other statuses) printed to stdout on startup on a box running inside Amazon VPC. 04:55:44,918 |-ERROR in ch.qos.logback.core.util.ContextUtil@5328f6ee - Failed to get local hostname java.net.UnknownHostException: ip-10-0-4-173: ip-10-0-4-173 at java.net.UnknownHostException: ip-10-0-4-173: ip-10-0-4-173 at at java.net.InetAddress.getLocalHost(InetAddress.java:1426) at at ch.qos.logback.core.util.ContextUtil.getLocalHostName(ContextUtil.java:32) at at ch.qos.logback.core.util.ContextUtil.addHostNameAsProperty(ContextUtil.java:41) at at ch.qos.logback.classic.joran.action.ConfigurationAction.begin(ConfigurationAction.java:56) at at ch.qos.logback.core.joran.spi.Interpreter.callBeginAction(Interpreter.java:276) at at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:148) at at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:130) at at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:50) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:157) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:143) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:106) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:56) at at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:75) at at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:148) at at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84) at at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:54) at at org.slf4j.LoggerFactory.bind(LoggerFactory.java:128) at at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:107) at at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:295) at at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:269) at at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:281) This is, unfortunately, breaking the tool that is running this code since it uses stdout to pipe data to other processes. (Seehttp://jira.qos.ch/browse/LOGBACK-292 for more on the fact that statuses are output to stdout even in the case of this automatic error-triggered output.) My config file is: <configuration> <appender name="STDERR" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%d [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> <target>System.err</target> </appender> <root level="WARN"> <appender-ref ref="STDERR"/> </root> </configuration> This config works, and all of the other statuses are just INFO's. I'm not using the hostname anywhere, and I do not care about it at all, so it's unfortunate that Logback seems to insist on complaining about it when I'm not actually using it. The "HOSTNAME" property is set presumably so that the property can be used during configuration. ContextBase#getProperty(String) already has a special case in it: public String getProperty(String key) { if (CONTEXT_NAME_KEY.equals(key)) return getName(); return (String) this.propertyMap.get(key); } What do you think about having another special case added to getProperty to lazy-load the hostname?

1 0

Filtering "unknown" mdc discriminator events
by Fred Toth 22 Sep '12

22 Sep '12

Hi, This has been written about before in this list, and I thought it would be easy, but I'm getting nowhere. Can anyone suggest what I'm doing wrong? I can confirm that my filter code is running (I see the print statements) but no matter what I return, I still end up with a log like "unknown/batchqc-<timestamp>" containing plenty of log data. I would like to eliminate these logs completely, and write logs using this sifter only when articlePath is set. The status listener is reporting: 12:03:35,652 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@25:37 - no applicable action for [OnMismatch], current pattern is [[configuration][appender][filter][evaluator][OnMismatch]] 12:03:35,652 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@26:34 - no applicable action for [OnMatch], current pattern is [[configuration][appender][filter][evaluator][OnMatch]] What am I missing? Config: <configuration> <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener"/> <timestamp key="bySecond" datePattern="yyyy-MM-dd-HH-mm-ss" /> <timestamp key="byDate" datePattern="yyyy-MM-dd" /> <appender name="ARTICLESIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator> <key>articlePath</key> <defaultValue>unknown</defaultValue> </discriminator> <sift> <appender name="ARTICLESIFT-APPENDER" class="ch.qos.logback.core.FileAppender"> <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> <evaluator class="ch.qos.logback.classic.boolex.JaninoEventEvaluator"> <expression> System.out.println("MDC: " + mdc + " " + mdc.get("articlePath")); if (mdc == null || mdc.get("articlePath") == null || ((String)mdc.get("articlePath")).contains("unknown")) return false; return true; </expression> <OnMismatch>NEUTRAL</OnMismatch> <OnMatch>DENY</OnMatch> </evaluator> </filter> <file>${articlePath}/batchqc-${bySecond}.log</file> <append>false</append> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %logger{0} - %msg%n </pattern> </encoder> </appender> </sift> </appender> <appender name="TSFILE" class="ch.qos.logback.core.FileAppender"> <file>logs/batchqc-${byDate}.log</file> <append>true</append> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %logger{0} - %msg%n</pattern> </encoder> </appender> <root level="info"> <appender-ref ref="TSFILE" /> <appender-ref ref="ARTICLESIFT" /> </root> </configuration> Thanks, Fred

2 4

How to use different xml settings file for logback depending on run.mode
by Olek Swirski 20 Sep '12

20 Sep '12

Hi, I'm using logback in a runnable jar containing a lift webapp. logback reads its settings from logback.xml file at the root of the jar. This runnable jar can be run in development mode by just using: java -jar myexecutable.jar but also in production mode: java -Drun.mode=production -jar myexecutable.jar I would like to be able to use different file for logback configuration depending on the run.mode. For example in default (development) mode this could be default.logback.xml (or just logback.xml as it is by default) and in production production.default.logback.xml or in test test.default.logback.xml How do I do that? In my app, there is a runnable object Start, with main method, where I probably could set some init options for logback depending on the run mode, which can be detected with System.getProperty("run.mode"). Here is the topic on lift mailing list, about this executable jar, and some last few messages are about trying to figure this out https://groups.google.com/forum/?fromgroups=#!topic/liftweb/uwwIA8FwmU8

2 2

Manually force the initialization of Logback
by GF 20 Sep '12

20 Sep '12

Hello everyone, I've a very uncommon configuration. I'm on SAP Netweaver AS :-( For some class loading reasons, I need to deploy separately a .ear file containing the Hibernate .jar files and all the .jar dependencies of hibernate (including log4j, slf4j-api and commons-logging) as a so called by SAP, "heavy resource" http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/bf0d57db-0c01-0010-6… Then I deploy separately the application .ear that does NOT contain the .jar already included in the hibernate .ear With log4j it worked. Now if... 1) I include all the logback libraries in the hibernate .ear I don't get any error, but when I deploy the application .ear logback doesn't start working! probably because the logback-* files are not in that .ear and they doesn't look for the logback.xml (that I included correcty, and locally on tomcat works...) And if.. 2) I include all logging related libraries in the application .ear when some of the classes of hibernate (that are in the other .ear) try to use something about logging, they got a class not found exception.. I'm totally confused, I'm trying to divide the libraries in many different combinations, but I didn't find any working solution. I think the case 1) might be ok, but I need to force the initialization of logback from the application.ear (that does not contain its libraries) How can I do that? can someone give me a SVN link to the code that starts all the logback stuff? I can even create just that class in my application to force logback initialization.. Thanks

1 0

LOGBACK-750 Syslogappender: missing stacktrace header lines
by Ingebrigt Berg 19 Sep '12

19 Sep '12

I've created http://jira.qos.ch/browse/LOGBACK-750 (which turned out to be a duplicate of http://jira.qos.ch/browse/LOGBACK-411) Also coded a fix and issued a pull request: https://github.com/qos-ch/logback/pull/61 cheers, Ingebrigt Berg

1 0