The code that is responsible for loading default log configuration makes it awkward to bundle a default `logback.xml` configuration and have a way to override this by dropping `logback.xml` in the work directory of the application.

I just took logback classic version `1.3.0-alpha14` for a test drive on a smallish project and after having configured the sane production defaults for the `logback.xml` in the bundled resources, found that I needed more verbose output.

To my dissapointment, when I dropped a slightly modified copy in the work directory of the launched application, I did not see any change in the log ouytput, so I went and digged in to the Logback configuration resolution algorithm and to my horror, I found that files bundled in the classpath are strictly preferred over files provided in the work directory.

The algorithm currently goes this way:

1. findConfigFileURLFromSystemProperties(myClassLoader, updateStatus);
   1. Given logback.configurationFile system property
   2. try to load resource from url
   3. if not a url, try loading it from classpath
   4. if that does not succeed, try loading configuration from filesystem
2. getResource(TEST_AUTOCONFIG_FILE, myClassLoader, updateStatus);
3. getResource(AUTOCONFIG_FILE, myClassLoader, updateStatus);

getResource is implemented as a call to ClassLoader.getResource(...), so effectively, the only way to override logging configuration of the application at deployment time is by specifying a file: url in logback.configurationFile system property with exact path to the configuration file.

The expected behavior would be to consult filesystem for configuration file before trying classpath. That way, the simplest way to override logging configuration would be just dropping a file in the file system and have logback pick that up at initialization time.