commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject [logging] proposed design for 1.0.5
Date Sun, 22 May 2005 01:54:36 GMT
Hi,

=========================
I would like to propose the following for jcl 1.0.5:

(a)
That we build diagnostic output into LogFactory/LogFactoryImpl which
users can turn on via a system property. NB: I'm about 80% done with the
implementation for this.

(b)
That in addition to commons-logging.jar we distribute a
"commons-logging-adapters.jar" which contains the entire contents of the
"impl" subdirectory, ie all the logging adapters and the concrete
LogFactory subclasses, but specifically NOT
   * LogFactory
   * Log

[this is along the lines of Brian's jar-refactoring proposal]

We should do away with commons-logging-api.jar; it serves no purpose.

(c) 
That we change the error message when multiple Log instances found, to
state that child should contain -adapters.jar not full jar.
 
(d)
That we provide the deployment instructions listed at the bottom of this
email.

(e) 
That we remove the weakref stuff that was added since 1.0.4 (sorry,
Brian!). The problem is that having Log deployed via the parent loader
and subclasses of Log (eg Log4JLogger) deployed via the child
classloader creates exactly the situation that renders the weakref stuff
useless. Instead, I would just document clearly that people should use a
ServletContextListener in situations where memory leaks matter. As I
describe below, I don't think it's all that often. We could also provide
cut-and-paste code to help them create and configure the
ServletContextListener - or maybe even bundle a suitable implementation
in the commons-logging.jar file.




I think that's *all* we need in order to resolve most of the current JCL
issues. The "Log4JLogger does not implement Log" should be completely
fixed by the jar refactoring. Discovery isn't changed, but the
diagnostics should make it easier for users to figure out what's going
on.

And the nice thing is it is almost a trivial change from 1.0.4.

We can then think about a JCL 1.1; I believe we can/should move towards
the SLF4J approach, while keeping the ability to plug in a LogFactory
class that does the lookup via context-classloader. This is pretty much
along the lines of Robert's DON_QUIXOTE stuff. It should completely fix
discovery issues (by doing away with discovery). There are also other
benefits but I'll post about that separately.

=========================

DEPLOYMENT INSTRUCTIONS FOR JCL 1.0.5

[no container]
* when not using a container
  --> deploy commons-logging.jar, be happy.

[child-first assumptions]
* when using a container that natively supports JCL
   (includes tomcat 5.0, 5.5)
   --> deploy commons-logging.jar or commons-logging-api.jar in shared
   --> deploy commons-logging-adapters.jar in child
   --> be happy
  Note that this setup normally would result in a leak (even when using
  weakreferences in LogFactory). However the container will be calling
  LogFactory.release(contextClassLoader) on unload, so all is good.

* when running a webapp that does not access any shared libs
   which use JCL:
   --> deploy commons-logging.jar in child
   --> be happy

* when running a webapp that accesses shared libs which use JCL
  and the container does not support JCL:
   --> deploy commons-logging.jar or commons-logging-api.jar in shared
   --> deploy commons-logging-adapters.jar in child
   --> use a ServletContextListener to call LogFactory.release on
       unload, in order to avoid memory leaks.

   NB: if you deploy commons-logging.jar in the child, you'll get an
   error message on startup telling you not to do this.

* when running a webapp that accesses shared libs which directly access
  the logging library that JCL maps to:
    --> put commons-logging.jar in the parent
    --> put commons-logging-adapters.jar in the child
    (a) put the concrete logging library in both parent and child.
        In this setup, you can configure logging done by child code
        at the child level. And logging done by code in the shared
        classes via JCL also goes to the logger configured at the
        child level. But logging done direct to the underlying
        logging lib by shared classes will go to a different instance
        of the logging library that is configured at the shared level.
    (b) put the concrete logging library only in the parent.
        All logging then goes to the same logging instance, but that
        logging instance must be configured at the global level and
        is shared across all webapps. 
  Neither (a) nor (b) is JCL's problem in my opinion.

[parent-first assumptions]
* when the preferred logging lib is available in child, but
  not available in the parent:
    --> put commons-logging.jar in parent
    --> put commons-logging-adapters.jar in child
    --> write your own null subclass of the concrete logger
        class (eg Log4JLogger)
    --> use JCL configurability to specify the logging adapter you want
        (eg via a services file in META-INF of the webapp).
    --> be happy

  Notes:
   * you can't just use JCL configurability to point to the normal
    Logger subclass (eg Log4JLogger), as that will be found in the
    commons-logging.jar file in the parent, and that will then fail
    to find the concrete logging lib in the parent. However as the
    custom Log4JLogger subclass will only be found in the child, it
    will be loaded by LogFactoryImpl, and because it was loaded via
    the child it *can* find the concrete logging lib in the child.

* when the preferred logging lib is available in the parent,
  and that logging library is "webapp-aware" (eg Log4J with
  ContextSelector enabled):
    --> put commons-logging.jar in parent
    --> put commons-logging-adapters.jar in child
    --> be happy

  A "webapp-aware" logging lib is one that will set up a separate
  logging "hierarchy" per context classloader, and look for config
  files within the context classloader path on initialisation.

* when the preferred logging lib is available in both parent 
  and child, and the logging lib is *not* webapp-aware:
    --> tough, you get global logging.




So now people can point out the obvious flaw in my arguments :-)

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message