- logback-user - mailman3.qos.ch

Appenders
by Greg Flex 16 Jun '09

16 Jun '09

Hi Ceki, I have a question about the LoggingEvent object. I'd like to log some messages by "building" (populating constructor) of LoggingEvent object, then log it with my appenders. I saw some sample code on line and what I have at the moment is this: Logger log; LoggingEvent event; Object[] args = {"test", "test2"}; //<-- I'm not sure exactly what this is for? event = new LoggingEvent("class", (Logger) LoggerFactory.getLogger("SimpleSocketServer"), Level.toLevel("DEBUG"), "test message", null, args); log = (Logger) LoggerFactory.getLogger("testClassName"); log.callAppenders(event); This works with my "CONSOLE" appender and I can see messages (with the passed values) printed. I have also a "DB" - database appender, to which I'd like to write as well, but something doesn't work.... I see a couple of "initialization" log messages in the database, (like port and waiting for clients to connect etc.) but not the one I'm building myself, even though as I stated above I can see it in the console. What am I doing wrong? Here is part of my config file: <configuration> <appender name="DB" class="ch.qos.logback.classic.db.DBAppender"> <connectionSource class="ch.qos.logback.core.db.DataSourceConnectionSource"> <dataSource class="com.mchange.v2.c3p0.ComboPooledDataSource"> <driverClass>com.mysql.jdbc.Driver</driverClass> <jdbcUrl>jdbc:mysql://localhost:3306/logging</jdbcUrl> <user>greg</user> <password>greg</password> </dataSource> </connectionSource> </appender>  <root> <level value ="DEBUG"/> <appender-ref ref="CONSOLE" /> <appender-ref ref="DB" /> </root> </configuration> UPDATE: I just did a little test and I added an HTML FILE appender. I see all messages there too, just like in CONSOLE appender case. but still nothing in the database except for the initialization messages. Any suggestions? Thanks Gregory.

1 0

Need Custom Appender
by Krishnendra Nandi 13 Jun '09

13 Jun '09

Hi I am looking for an appender which takes the variables from within the thread to create a logfile I have multiple threads spawning from a main thread .This threads take a seperate file for processing and i need a log by that filename Any pointers to that would be helpful -- Thanks and Regards Krishnendra Nandi Phone :+919921514085 Skype :krish_nandi_78 Gtalk :krishnendra@gmail.com

2 1

Best practices to avoid deadlocks while logging
by Olivier Cailloux 13 Jun '09

13 Jun '09

Dear list, I recently had a deadlock problem related to logging and I am wondering if it comes from a problem in the logging framework (I must say I doubt it) or from the way I use logging, in which case I'd like to hear advices about how others avoid this kind of problems. The pattern is the following. (Please see hereby the java classes which might be clearer.) - In a class "Worker", a method "work()" locks the object instance of the class Worker to do some work and calls the logging framework to print the result (while still holding the lock). - In the same class "Worker", an other method "getStatus()" obtains the current status of the object instance of the class Worker and returns it as a String (method used for logging). That method locks the object at some point to make sure it reads consistent internal status information. - In an other class "Accessor", a method "access()" performs some work (not locking anything), then logs the status of an object of the class Worker by using its getStatus() method. Now the deadlock scenario is the following. - A thread "WorkerThread" is executing the method "work()". It has acquired the lock for the Worker object and has not reached the logging statement yet. - An other thread "AccessorThread" is executing the method "access()", and is executing the logging statement. AFAIU, logback console logger has some sort of "central" locking point: when a thread is logging, an other thread may not log in parallel (that seems good as the user does not want his different logging statements to be mixed together)... Thus, the following happens. - AccessorThread has a lock to the Logger, and waits to acquire the Worker lock to execute the synchronized block in getStatus(). - WorkerThread is holding that precise lock, and will never release it, because arriving at the logging statement in "work()", it starts waiting for the Logger lock acquired by AccessorThread. These two threads are caught in a deadlock. I feel the problem comes from not respecting the general rule that a block of code holding a lock should not call a method on an externally controlled object (possibly shared with other threads) whose locking behavior is unknown. (Note that both my code and the logging framework do not respect this rule, AFAIK.) So I should not have issued the log statement in my synchronized block in "work()". In my case, I can remove this logging statement from the synchronized block, but it is not clear to me whether it is always possible (or easy) to do so, especially if the thing you want to log depends on an internal state which might change as soon as you release the lock. An other way to solve that problem is to not use the parametrized message system in SLF4J. Indeed, it would disable the possibility of the AccessorThread to try to acquire the lock on Worker while being in the SLF4J method. I am wondering however if there is not a way that slf4j implementation (logback) release the lock on its logger, then gets the Worker lock, then re-acquire the lock on its logger only after having released the Worker lock, so that it has only one lock at a time? I tend to think that it would enable a user of the logging framework to pay no attention of the deadlock possibilities incurred by the logging framework, and to avoid him introducing subtle bugs with logging statements... But I may be wrong and I am not an expert in multithread programming. More generally speaking, what would be the advices from experienced programmers to avoid this problem? How do you log in a multithreading context? Also I am wondering if that (anti-)pattern could be documented on the logback page, to avoid others to do the same mistake as me? Or even on the SLF4J page, if it is not logback-specific? The attached classes provide a test case showing the deadlock scenario. The test fails reliably on my box. Thank you for any help. Olivier

3 7

Redeploying application on Tomcat 5.5 gives NullPointerException
by Thorbjørn Ravn Andersen 09 Jun '09

09 Jun '09

I just redeployed a WAR file on a Windows based Tomcat 5.5. server, after which reloading the login jsp-page resulted in the following stack trace: java.lang.NullPointerException ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:121) ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:437) ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:393) ch.qos.logback.classic.Logger.log(Logger.java:812) org.apache.commons.logging.impl.SLF4JLocationAwareLog.debug(SLF4JLocationAwareLog.java:120) org.apache.catalina.connector.Request.getRequestDispatcher(Request.java:1219) org.apache.catalina.connector.RequestFacade.getRequestDispatcher(RequestFacade.java:569) org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:402) org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234) org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384) javax.faces.webapp.FacesServlet.service(FacesServlet.java:138) org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144) com.foo.axsWHSweb.servlet.filters.LoggedInToAxsFreightFilter.doFilter(LoggedInToAxsFreightFilter.java:59) There is jcl-over-slf4j-1.5.5.jar, slf4j-api1.5.6, logback-classic 0.9.14 and logback-core-0.9.14 in the classpath. Is this a known and fixed issue (so I should upgrade all to the newest) or should I investigate? I believe there has been added an appender in logback.xml with a layout based on a class not present in the previous version of the war. -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"

2 3

Appender question
by muleman 09 Jun '09

09 Jun '09

I built an appender that buffers messages and it will write the content to the appender on the stop method. With this appender I want to collect messages that are related to a specific Object instance in my application. For example; I want to collect all messages that belong to one ProcessingRequest. Once this request is completed I want to flush it out to a Space as one string plus host and some more info.... I noticed that the appender does not exist any more after I call the stop method. Furthermore it looks like appenders are not created on a per logger basis, there seems to be just one appender instance .... Is there a way to force a new appender instance for each logger ? Thanks Chris -- View this message in context: http://www.nabble.com/Appender-question-tp23922806p23922806.html Sent from the Logback User mailing list archive at Nabble.com.

1 3

conditionals in logback.xml?
by Thorbjørn Ravn Andersen 04 Jun '09

04 Jun '09

Hi I would like to be able to only enable certain appenders if a given condition is true (based on e.g. a property file). Is there a simpe way to do this with logback.xml or must I configure Joran myself? Thanks -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"

3 4

Question
by Louie Liu 02 Jun '09

02 Jun '09

We have the following use case and would like to know what is the best practice in logback framework. Basically, we are trying to use the SMTP logger appender to send alert email when the erorr is occured. The issue is that we would like to generate a summary messages (which including, for example, about 100 errors which occured within the given time frame) and send only one email. The reason for it is to reduce the number of email to avoid flush the email server. Please let us know what is the best way to configure the logback to satisfy the use case above. Thanks a lot. Louie

3 2

Logback with Postfix
by Brian Moschel 02 Jun '09

02 Jun '09

I'm trying to set up logback for use with Postfix running locally on the same machine as my app. I am using the following: <appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender"> <SMTPHost>localhost</SMTPHost> <To>brian.moschel(a)gmail.com</To> <From>brian.moschel(a)gmail.com</From> <Subject>TESTING: %logger{20} - %m</Subject> <layout class="ch.qos.logback.classic.html.HTMLLayout"/> </appender> This does not work though. It hangs forever and my local mail logs never receive a request. The local mail server is running at port 25. I can run "mail <some email address> to sucessfully mail someone on this machine. Any ideas how to debug this? Thanks, Brian

3 2

AUTO: Manfred Kuhlmann is out of office. (Rückkehr am 25.05.2009)
by Manfred.Kuhlmann＠steria-mummert.de 20 May '09

20 May '09

Ich werde ab dem 20.05.2009 nicht im Büro sein. Ich kehre zurück am 25.05.2009. I will be out of the office starting 20.05.2009. I will be back on 25.05.2009. Ihre Nachricht werde ich nach meiner Rückkehr beantworten. I will answer your message after my return. Mit freundlichen Grüßen Best regards Manfred Kuhlmann Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht " [logback-user] Best practices to avoid deadlocks while logging" gesendet am 20.05.2009 18:31:46. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist.

1 0

Best practices to avoid deadlocks while logging - test case
by Olivier Cailloux 20 May '09

20 May '09

Dear list, I recently had a deadlock problem related to logging and I am wondering if it comes from a problem in the logging framework (I must say I doubt it) or from the way I use logging, in which case I'd like to hear advices about how others avoid this kind of problems. The pattern is the following. (Please see hereby the java classes which might be clearer.) - In a class "Worker", a method "work()" locks the object instance of the class Worker to do some work and calls the logging framework to print the result (while still holding the lock). - In the same class "Worker", an other method "getStatus()" obtains the current status of the object instance of the class Worker and returns it as a String (method used for logging). That method locks the object at some point to make sure it reads consistent internal status information. - In an other class "Accessor", a method "access()" performs some work (not locking anything), then logs the status of an object of the class Worker by using its getStatus() method. Now the deadlock scenario is the following. - A thread "WorkerThread" is executing the method "work()". It has acquired the lock for the Worker object and has not reached the logging statement yet. - An other thread "AccessorThread" is executing the method "access()", and is executing the logging statement. AFAIU, logback console logger has some sort of "central" locking point: when a thread is logging, an other thread may not log in parallel (that seems good as the user does not want his different logging statements to be mixed together)... Thus, the following happens. - AccessorThread has a lock to the Logger, and waits to acquire the Worker lock to execute the synchronized block in getStatus(). - WorkerThread is holding that precise lock, and will never release it, because arriving at the logging statement in "work()", it starts waiting for the Logger lock acquired by AccessorThread. These two threads are caught in a deadlock. I feel the problem comes from not respecting the general rule that a block of code holding a lock should not call a method on an externally controlled object (possibly shared with other threads) whose locking behavior is unknown. (Note that both my code and the logging framework do not respect this rule, AFAIK.) So I should not have issued the log statement in my synchronized block in "work()". In my case, I can remove this logging statement from the synchronized block, but it is not clear to me whether it is always possible (or easy) to do so, especially if the thing you want to log depends on an internal state which might change as soon as you release the lock. An other way to solve that problem is to not use the parametrized message system in SLF4J. Indeed, it would disable the possibility of the AccessorThread to try to acquire the lock on Worker while being in the SLF4J method. I am wondering however if there is not a way that slf4j implementation (logback) release the lock on its logger, then gets the Worker lock, then re-acquire the lock on its logger only after having released the Worker lock, so that it has only one lock at a time? I tend to think that it would enable a user of the logging framework to pay no attention of the deadlock possibilities incurred by the logging framework, and to avoid him introducing subtle bugs with logging statements... But I may be wrong and I am not an expert in multithread programming. More generally speaking, what would be the advices from experienced programmers to avoid this problem? How do you log in a multithreading context? Also I am wondering if that (anti-)pattern could be documented on the logback page, to avoid others to do the same mistake as me? Or even on the SLF4J page, if it is not logback-specific? The attached classes provide a test case showing the deadlock scenario. The test fails reliably on my box. Thank you for any help. Olivier

1 0