commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject [logging] new release?
Date Fri, 07 Oct 2005 09:16:13 GMT
Hi All,

A week or so ago I was prompted by new activity on the logging topic to
review what is currently sitting in SVN. I think it's actually quite
good, and perhaps we could try to push for a release.

The issues I'm aware of are:
* Do we include the ServletContextListener stuff or not? And if we do,
  do we put it in an "optional" jar or in the main jar?

  Personally, I would like to include it, and put it in the main jar.
  It does no harm being there, as no logging classes reference it. It
  only gets used if someone explicitly references it from a web.xml

  There have been objections about adding "dependencies", but JCL is
  a project that already has heaps of compile-time dependencies that
  aren't actually runtime dependencies, eg LogKit is a compile-time
  dependency too, but isn't needed to run.

* Do we include the WeakHashtable stuff or not? And if so, do we
  put it in an "optional" jar or in the main jar. On the positive
  side, it will fix memory leaks for many people. And on JDKs that
  don't support weak references JCL politely falls back to a standard
  hashtable. On the negative side it isn't a 100% fix; it won't work
  if the LogFactoryImpl is loaded from a parent loader but the log
  adapter class is loaded from the webapp. This isn't a common
  situation, but a partial fix can be confusing. And the
  ServletContextListener should be a 100% fix. The other concern is
  that it is a lot of new - and quite tricky - code.

  I can't make up my mind on this. I'm tempted to put it in an optional
  jar. However if we put it in the main jar, then (a) we don't need to
  document its use so much, and (b) we could do away with the optional
  jar completely which would be nice.

* There's a proposal to add a system property to disable all TCCL use.
  It's worth considering. 

* There's a proposal to add "get logger name" functionality.

* We still don't handle "cross-application" calls. Apparently by using
  JCA or similar one component can get a reference to an object in
  another container and make a call to it. In that case, there is
  absolutely no way the existing code can load a log adapter class from
  the contextClassLoader and cast it to a Log implementation.
  Currently, we walk the classloader ancestry chain looking for which
  loader is a child of which, and find they aren't related so panic.
  Perhaps we could just fall back to using diagnostic logging to output
  a message, then assign a NoOp logger?

* How do we handle Log4J 1.2->1.3 stuff? Some people have offered to
  investigate whether a single class can handle both versions. If that
  doesn't work out, then what? Currently, SVN has *removed* the
  Log4JLogger class, and added Log4J12Logger/Log4J13Logger. My reasons
  are documented in a recent email to this list (or was it the user
  list?). It's obviously up for debate though.

  And do we want to offer 1.3 support, given that 1.3 is still alpha?
  I would prefer not to; better to provide a minor release after
  log4j 1.3 is released than provide ahead-of-time support and get
  it wrong. Actually, for the current release we could provide a
  Log4JLogger class with TRACE support, and worry about splitting
  into log4j1.2/1.3 when the new version comes along. I would still
  like to see the version-checking stuff in the Log4J12Logger class
  kept, though.

Anything else??

Note that I'm still very short of time at the moment. I'd really like to
see a new JCL release, but can't promise to contribute much towards it
at the moment.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message