[logback-dev] App Servers and Thread.contextClassLoader

[Ceki Gulcu]

Hi Robert,

Robert Elliot wrote:
 > Slightly odd question, but it is logback related.  I'm writing a
 > library to redirect System.out and System.err to SLF4J.  I'm
 > envisaging this being used in application servers.  I'd like it to
 > work "correctly" with SLF4J implementations like Logback, so if the
 > app server has child first class loading and SLF4J and logback are in
 > webapp A's lib dir, a call to System.out.println within webapp A will
 > be handled as per the logback.xml in webapp A's classes folder,
 > regardless of other webapps with different config.

A per class-loader approach is similar to that of commons-logging.  As
you know, SLF4J has a different philosophy whereby it will ignore the
value returned by Thread.currentThread().getContextClassLoader() and
only use the class loader which loaded SLF4J itself (i.e. the class
loader which loaded the SLF4J classes).

The general problem is called the logging separation problem which is
deemed to be exceedingly difficult to solve correctly for all
environments. As such, my recommendation would be to ignore the
logging separation issue by delegating it to SLF4J.

 > The only way that is possible (as far as I can see) is to work out
 > from the thread calling the System.out methods which web app it was
 > that made the call - and I've found the method getContextClassLoader
 > on Thread which looks hopeful!  However, I'm not completely confident
 > that app servers that implement child first class loading will set
 > that to the a web app specific class loader.

Yes, as far as I know, the app server will set the web app specific
class loader for the current thread.  If you generalize the context,
for example to include build systems (Ant, Maven, Ivy, etc), then
things get a little muddier. For example, I believe that earlier
versions of Ant did not set the thread context class loader.

As for your goal, most application servers have their own way of
capturing and redirecting the console. So you may be facing a big
hurdle in order to get an app server to adopt your library.

Anyway, is it correct to assume that you wish to tackle bug 110 [1]
outside SLF4J?


[1] http://bugzilla.slf4j.org/show_bug.cgi?id=110

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch