[logback-user] log files locked after application undeploy

Ceki Gulcu listid at qos.ch
Tue Jun 3 18:24:08 CEST 2008


Hello Syvalta, Anton,

Anton's recommendation to invoke

((LoggerContext)LoggerFactory.getILoggerFactory()).shutdownAndReset()

within a contextDestroyed method of a ServletContextListener is
exactly right.

His later mention of the Context Selector chapter in the logback
manual is also relevant, but only if slf4j-api.jar and
logback-classic.jar are shared between application (as he also
mentioned).

I think the problem you are facing merits an entry in the docs, at
least in the FAQ. Syvalta, would you mind entering a bug report in
http://jira.qos.ch on this subject? The contents of your email are
sufficient for creating the entry. (If you do mind, please let me know
and I'll take care of it.)

HTH,

Anton Tagunov wrote:
> Hello Syvalta,
> 
> Please notice: this is an advice from user not from logback developers.
> 
> [1]
> am I right that slf4j and logback jars 
> * are provided by the web application itself?
> * not provided as shared jars by the Servlet container?
> 
> in this particular case you can write a ServletContextListener
> that will do a very simple thing in contextDestroyed():
> 
> public void contextDestroyed(ServletContextEvent servletContextEvent) {
> ((LoggerContext)LoggerFactory.getILoggerFactory()).shutdownAndReset()
> }
> 
> you will also need to register this context listener in web.xml
> <listener>
> <listener-class>ch.qos.logback.classic.selector.servlet.ContextDetachingSCL</listener-class>
> </listener>
> 
> [2]
> HOWEVER please note that the setup you're using is somewhat fragile.
> 
> If your applicaiton is deployed within a web container that
> * does provide logback.jar in classloader shared between web applications
> * the classloader used by this servlet container to load your web
>   application works in normal parent first order
> then you may have issues.
> 
> The issues that may happen inlude logback being configured by web-container wide
> logback.xml, not by logback.xml provided within your application.
> Another possible issue is that the ServletContextListener suggested above
> will close logging not for your application only but for other applications also.
> 
> [3]
> The suggested logback setup in a servlet container is described in logback manual
> http://logback.qos.ch/manual/contextSelector.html
> It is suggested to perform this setup in full including JNDI parameter configuration.
> 
> If you would like to have more details on why such complex setup is needed
> you can find them here
> http://wiki.apache.org/jakarta-commons/Logging/StaticLog
> http://www.qos.ch/logging/sc.jsp
> 
> These article discuss other logging libraries but the problem being solved is essentially the same.
> 
> with best regards,
> Anton Tagunov
> 
> On Tue, 3 Jun 2008 02:21:56 -0700 (PDT)
>  Syvalta <syvalta at yahoo.com> wrote:
>> I have a minor problem with logback (version 0.99). When I undeploy my web
>> application the log files are still locked and they remain locked (under
>> Windows).
>>
>> How is this supposed to work? Is this expected behavior, or does that mean I
>> have a resource leak in my application? I see appenders do have stop method,
>> but I didn't find any overall shutdown method in Logback. How is log file
>> closing supposed to work?
>>
>> I have logback.xml in my classpath and I'm not doing any explicit
>> initialization. I use RollingFileAppender with TimeBasedRollingPolicy.
> 
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://qos.ch/mailman/listinfo/logback-user



More information about the Logback-user mailing list