[ http://jira.qos.ch/browse/LBCORE-18?page=com.atlassian.jira.plugin.system.is... ] Ceki Gulcu commented on LBCORE-18: ---------------------------------- Hello Filip, Thank you for reporting this problem. In logback 0.9.14, ContextInitializer.autoConfig uses the class loader which loaded the ContextInitializer class to search for resources (logback-test.xml and logback.xml). It does not use TCCL. Please let me know if this works for you so that I can close this bug.

classloader for loading autoConfig configuration resource ---------------------------------------------------------

Key: LBCORE-18 URL: http://jira.qos.ch/browse/LBCORE-18 Project: logback-core Issue Type: Bug Components: Other Affects Versions: unspecified Environment: Operating System: Windows Platform: PC Reporter: Filip Jirsák Assignee: Logback dev list Priority: Blocker Attachments: classloader.patch

ContextInitializer.autoConfig(LoggerContext) uses current thread context ClassLoader (TCL) nowadays - it calls Thread.currentThread().getContextClassLoader(). Sometimes this classloader has no access to logback classes - for example TCL is parent of classloader, which loaded current class, in oc4j (Oracle J2EE container) at the time of starting servlet container. So logback-*.jar are in WEB-INF/lib directory, but TCL has no access to these jars and to files in WEB-INF/classes. I think ContextInitializer.autoConfig(LoggerContext) should try this.getClass().getClassLoader() first and only if it fails it should use Thread.currentThread().getContextClassLoader().

-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira