commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [logging] What's needed for a release
Date Sun, 13 Nov 2005 20:30:47 GMT
On Sat, 2005-11-12 at 19:24 +0100, Dennis Lundberg wrote: 
> robert burrell donkin wrote:
> > On Sat, 2005-11-12 at 08:05 +1300, Simon Kitching wrote:
> >> On Thu, 2005-11-10 at 22:40 +0000, robert burrell donkin wrote:
> >>> On Thu, 2005-11-10 at 21:04 +1300, Simon Kitching wrote:


> >> * Sort out whether we split Log4JLogger into two classes or not.
> > 
> > yep needs sorting :-/
> There is one more thing to consider here. If we choose two classes, how 
> should we name them? This has to do with backward compatibility.


> In SVN there are currently two classes named and 
> In configuration terms this means that if a user 
> that uses a configuration file to select the logging implementation, and 
>   wants to upgrade from JCL 1.0.4 to the new version, will need to 
> change their configuration. How do we feel about this? In my book that 
> means that the new version of JCL is not a drop-in replacement for the 
> previous version and would warrant it a 1.1 version number. Thoughts?
> One idea would be to rename back to 
> That would make the upgrade transparent for the previous use-case. But 
> there is the chance that this will not work at all for a user that is 
> currently using JCL 1.0.4 together with log4jalpha-something and a 
> configuration file stating that Log4JLogger should be used.

i would much prefer the next release to be fully semantically compatible
(though perhaps we might decide to call it 1.1). however, users who
configure JCL to use Log4JLogger might reasonably expect JCL to guess
the log4j version and use the correct logger. so, perhaps one option
would be to create a delegating implementation. 

> > opinions?
> I like the idea of two files. A while back I did a quick analysis of 
> what changes has been done in Log4J between 1.2 and 1.3. I could not 
> find a way to make it work with just one logging implementation file in JCL.
> >> * Verify that TRACE support works for log4j's latest releases.
> > 
> > +1
> > 
> > volunteers?
> I can help out with this.


> Which versions are we talking about here? Here's a rundown of the ones 
> that should be considered:
> 1.2.6 seems to be what is required for running JCL
> 1.2.9 is mentioned in build.xml
> 1.2.12 implements trace support and is the compilation dependency 
> version in project.xml
> 1.2.13rc1 was tagged three weeks ago and contains fixes related to TRACE 
> level
> 1.3.0 is only found in build.xml but it has mention of a more specific 
> version. 1.3alpha-7 is the latest tag I found in Log4Js SVN.
> If it were up to me I'd pick these:
> 1.2.6 make sure TRACE goes to debug
> 1.2.12 make sure TRACE goes to trace
> 1.3alpha-7 make sure TRACE goes to trace
> What do you think?

that sounds about right but could do with testing the 1.2.13 release
candidate as well (just in case).

- robert

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

View raw message