December 2009 - logback-user

org.slf4j.impl.StaticLoggerBinder.SINGLETON
by Rusty Wright 25 Oct '11

25 Oct '11

I'm unable to create a bugzilla account at http://bugzilla.slf4j.org/createaccount.cgi Could someone enter this bug report for me? If I change my version of logback to 0.9.11 I don't get this. I get it when I use logback version 0.9.13. I'm using version 1.5.5 of slf4j. Thanks Running TestSuite org.apache.maven.surefire.booter.SurefireExecutionException: Cannot instantiate class edu.berkeley.ist.cars.net.email.EmailTest; nested exception is org.testng.TestNGException: Cannot instantiate class edu.berkeley.ist.cars.net.email.EmailTest org.testng.TestNGException: Cannot instantiate class edu.berkeley.ist.cars.net.email.EmailTest at org.testng.internal.ObjectFactoryImpl.newInstance(ObjectFactoryImpl.java:35) at org.testng.internal.ClassHelper.createInstance(ClassHelper.java:330) at org.testng.internal.ClassImpl.getDefaultInstance(ClassImpl.java:62) at org.testng.internal.ClassImpl.getInstances(ClassImpl.java:81) at org.testng.internal.TestNGClassFinder.<init>(TestNGClassFinder.java:114) at org.testng.TestRunner.initMethods(TestRunner.java:281) at org.testng.TestRunner.init(TestRunner.java:227) at org.testng.TestRunner.init(TestRunner.java:189) at org.testng.TestRunner.<init>(TestRunner.java:138) at org.testng.SuiteRunner$DefaultTestRunnerFactory.newTestRunner(SuiteRunner.java:477) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:244) at org.testng.SuiteRunner.run(SuiteRunner.java:198) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:821) at org.testng.TestNG.runSuitesLocally(TestNG.java:788) at org.testng.TestNG.run(TestNG.java:708) at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:62) at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:141) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.testng.internal.ObjectFactoryImpl.newInstance(ObjectFactoryImpl.java:26) ... 23 more Caused by: java.lang.IllegalAccessError: tried to access field org.slf4j.impl.StaticLoggerBinder.SINGLETON from class org.slf4j.LoggerFactory at org.slf4j.LoggerFactory.staticInitialize(LoggerFactory.java:83) at org.slf4j.LoggerFactory.<clinit>(LoggerFactory.java:73) at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155) at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:131) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:272) at org.springframework.test.context.testng.AbstractTestNGSpringContextTests.<init>(AbstractTestNGSpringContextTests.java:77) at edu.berkeley.ist.cars.net.email.EmailTest.<init>(EmailTest.java:21) ... 28 more

4 5

LoggingContext JNDI not working in Session EJB using Thread
by miguel goyena 07 Jan '10

07 Jan '10

Hi everybody: I'm starting using logback, and I have a strange behauvour of logback. I'm using LoggingContextSelect JNDI. My application es an ear deployed in JBOSS, with three WAR and a EJB session jar. One of the servlet in a WAR uses the Sesssion EJB. In the EJB Session Method I create a Thread, and start it MandarMensajes threadException = new MandarMensajes(tipo,cuantos,cadaCuanto); threadException.start(); In this thread the run method uses logback for logging. Logger logger = LoggerFactory.getLogger(this); logger.logDebug("Hola"); But the logger I get have a default context!!!!!!, not the context defined in the JNDI. Only happends this when a use the thread in the Session EJB. If I use the MandarMensajes thread in the servlet everything is correct. If I get a logger anywhere else in the EJB Session everything is correct. If I use the run() method in the EJB Session everything is correct. Even if I get the MDC objet when thread is executing, all the values I put in servlet are there; but the context is default, so it never uses my logback.xml!!!!. I don't know if it is a logback bug, or if I'm doing something wrong I don't know if I've explained myself correctly, sorry my english is poor Thanks a lot

2 3

Release of logback v0.9.18
by Ceki Gülcü 06 Jan '10

06 Jan '10

Hello all, I am happy to announce the immediate availability of logback version 0.9.18, consisting mainly of bug fixes and minor enhancements. After a very long investigation resulting in somewhat a better understanding of licensing issues, logback is now dual-licensed under the EPL 1.0 and LGPL 2.1. 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 QOS.ch announce mailing list. To subscribe to QOS.ch announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/announce -- Ceki

2 1

StatusListenerAction does not set context to ContextAware StatusListener
by Tom Liu 06 Jan '10

06 Jan '10

Hi, In logback 0.9.17/0.9.18, StatusListenerAction does not set context to ContextAware StatusListener. Is it by design? Thanks, Tom

3 4

Reading an environment variable for conf purposes
by pablo fernandez 03 Jan '10

03 Jan '10

Hi, I have this logback.xml file: <configuration debug="true" scan="true" scanPeriod="60 seconds"> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</Pattern> </layout> </appender> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${MY_HOME}/logs/mylog.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>logs/my.%d{yyyy-MM-dd}.log</FileNamePattern> <MaxHistory>30</MaxHistory> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d{HH:mm:ss.SSS} [%thread] %-5level - %msg%n</Pattern> </layout> </appender> <root level="TRACE"> <appender-ref ref="FILE"/> </root> </configuration> And ${OSC_HOME} is a defined system variable (echo $OSC_HOME on linux shows the correct path). The thing is that logback doesnt seem to read it properly, it stores the logs under OSC_HOME_IS_UNDEFINED/logs/my.log What am I doing wrong? Thanks a lot! -- Fernandez, Pablo.

2 1

LoggerContext.stop()
by Jeff Jensen 28 Dec '09

28 Dec '09

It seems the code in [1] and [2] do the same thing - call LoggerContext.stop(). Is this true (and therefore only need ContextDetachingSCL), or are both needed in a "thorough web app shutdown"? [1] Section "Hot deploying applications" on page http://logback.qos.ch/manual/loggingSeparation.html [2] Section "Avoiding memory leaks" http://logback.qos.ch/manual/jmxConfig.html#leak

2 2

AUTO: Manfred Kuhlmann is out of office. (Rückkehr am 11.01.2010)
by manfred.kuhlmann＠steria-mummert.de 23 Dec '09

23 Dec '09

Ich werde ab dem 23.12.2009 nicht im Büro sein. Ich kehre zurück am 11.01.2010. I will be out of the office starting 23.12.2009. I will be back on 11.01.2010. Ihre Nachricht werde ich nach meiner Rückkehr beantworten. I will answer your message after my return. Bitte Ihre Ansprechpartner in der Mitarbeiterdatenbank unter dem Reiter 'Abwesenheitsvertreter' eingeben (s.a. Hilfe-Button). Mit freundlichen Grüßen Best regards Manfred Kuhlmann Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht "Re: [logback-user] Logback suddenly stopped logging" gesendet am 23.12.2009 01:37:24. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist. Steria Mummert Consulting AG Vorsitzender des Aufsichtsrates: Jürgen Sponnagel - Vorstand: Oliver Nazet (Vors.), Dr. Fritz Moser Gesellschaftssitz: Hamburg - HR B 61 116 Amtsgericht Hamburg - USt-ID-Nr.: DE118671351 Bitte denken Sie an Ihre Verantwortung gegenüber der Umwelt: Jede ausgedruckte E-Mail verursacht ca. 0,3 Gramm CO2. Diese Nachricht kann vertrauliche Informationen enthalten und ist allein für den Adressaten bestimmt. Wenn Sie nicht der rechtmäßige Empfänger sind, ist der Zugriff, die Weiterleitung, das Kopieren, die Veröffentlichung oder anderweitige Verwendung des Inhalts untersagt. In diesem Fall bitten wir Sie den Absender unverzüglich zu informieren und diese E-Mail sowie sämtliche Kopien dieser Email zu löschen. Der Inhalt von E-Mails innerhalb des Netzwerks kann überprüft werden, um die Übereinstimmung mit den geltenden Firmenrichtlinien und Vorgehens-weisen zu gewährleisten. E-Mails können auf dem Transportweg von Dritten verändert werden, so dass deren Vollständigkeit und Echtheit nicht garantiert werden kann. This Email communication may contain confidential information and is intended only for the recipient. If you are not the intended recipient you are not allowed to read, copy, distribute, publicize or use the content of this Email in any way. Please notify the sender and delete the Email and any copies of it. The content of Emails within our network may be monitored to ensure compliance with company policies and procedures. Emails can be alterated by third parties in transit. Therefore any Email is susceptible to alteration and its integrity cannot be assured.

1 0

Logback suddenly stopped logging
by Jorge Morales Pou 23 Dec '09

23 Dec '09

We have logback configured with this configuration: <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <Append>true</Append> <file>logs/process.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>logs/process-%d{yyyy-MM-dd_HH}.%i.log</FileNamePattern> <TimeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <MaxFileSize>1MB</MaxFileSize> </TimeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%date|%level|%logger{10}|%msg|%throwable{5}%n</Pattern> </layout> </appender> The thing is that in our production environment (HP-UX) and under heavy load, logging was working fine for a time, and suddenly stop working. >From the status we see this: INFO in c.q.l.co.rolling.helper.RenameUtil - Renaming file [/gp/log/process.log] to [/gp/log/process.2009-12-16_11.22.log], ERROR in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - IO failure in appender java.io.InterruptedIOException: , WARN in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - Attempted to append to non started appender [FILE]., WARN in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - Attempted to append to non started appender [FILE]., WARN in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - Attempted to append to non started appender [FILE]., INFO in c.q.l.co.rolling.helper.RenameUtil - Renaming file [/gp/log/application.log] to [/gp/log/application.2009-12-16_11.log]]

2 1