Ceki Gulcu wrote:

Hello Ted, The question was discussed in a previous thread: http://www.qos.ch/pipermail/logback-user/2007-September/000329.html

Note also that in that thread I attached code that may be used to obtain a periodic configuration reloader in Spring: even without Spring, using a timer to trigger the reload is a pretty simple task. -- View this message in context: http://www.nabble.com/%22Watching%22-the-config-file-tf4571293.html#a1329069... Sent from the Logback User mailing list archive at Nabble.com.

Note also that that solution allows using a work manager thread from the application server: using a library that creates and manages threads by itself (as Log4j config reloader does) is strongly discouraged (in fact log4j thread may not be shut down at web application reloads and creates class loader problems upon reloading).

I have a several applications, each with a Main method. Having the library create and manage a thread for me is not a problem in my application, writing the thread to watch and reload is a pain. I'm not saying your objections are valid, just that there are scenarios where automatic reloading would be a very useful feature. While I could create a class that encapsulates the thread that watches and reloads the config, it doesn't seem like every user of logback should have to write that class. I'm also using logback via slf4j, and writing that class would couple my application to logback. I'm fine with the watchConfig config file setting having some disclaimers or warnings on it, but I think it needs to exist. Ted