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