[monolog] LogManager#addLogger breaks classloader isolation (was: Re: Monolog on gcj)

[Vadim Nasardinov <vadimn@xxxxxxxxxx>]

On Thursday 18 August 2005 12:13, Andrew Haley wrote:
> Java has a class called java.util.logging.LogManager, and you can get
> a Logger by calling getLogger:
> 
>  Logger getLogger(String name)
> 
> but LogManagers only keep weak references to their logs.  So, as soon
> as a log has been created you need to keep a hard reference to it.
> 
> In Monolog there is
> org.objectweb.util.monolog.wrapper.javaLog.LoggerFactory, and that
> uses a LogManager to keep track of the instances of Logger it
> creates

Monolog's reliance on java.util.logging.LogManager is probably a bad
idea for reasons hinted at by this thread:

- http://mail-archive.objectweb.org/architecture/2004-06/msg00013.html
  Message-Id: <200406211159.27672@xxxxxxxxxxxxxxxx>
- http://www.qos.ch/logging/sc.jsp

The problem is that it is currently impossible to have two copies of
Monolog loaded by two distinct classloaders.  You end up having two
distinct copies of the
org.objectweb.util.monolog.wrapper.javaLog.LoggerFactory class, but
they both talk to the same java.util.logging.LogManager instance.
This leads to Logger instances being shared between two isolating
classloaders.

This inevitably leads to ClassCastExceptions, because LF1
(LoggerFactory #1) expects its Logger instances to be of class
CL1.org.objectweb.util.monolog.wrapper.javaLog.Logger (where CL1 is
classloader #1), whereas LF2 expects its Logger instances to be of
class CL2.org.objectweb.util.monolog.wrapper.javaLog.Logger.  Since
CL1 and CL2 are siblings that can't see each other, you can't cast
CL1.org.objectweb.util.monolog.wrapper.javaLog.Logger to
CL2.org.objectweb.util.monolog.wrapper.javaLog.Logger.

So, this whole notion of using java.util.logging.LogManager may need
to be rethought.

As a point of reference, it should be noted that the *other* wrapper
framework doesn't use LogManager#addLogger at all.