commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <>
Subject Re: [logging] What's needed for a release
Date Sat, 12 Nov 2005 18:24:21 GMT
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:
>>> <snip>
>>>>> Can a new release of CL rule out all the classloading problems
>>>>> people had before?
>>>> What's currently in SVN head will probably fix 90% of the problems, and
>>>> is about 99% backwards compatible. I would love to see it released, so
>>>> that the debate could then move on to a "JCL 2.0" which I think is quite
>>>> likely to take the alternative approach described above. Oh for a few
>>>> more hours in the day!
>>> what work's required for a release (above the actual code cutting)?
>> * Remove the ServletCleanupContextListener (this might not be exactly
>> the right class name). It's obviously too controversial. Maybe the code
>> could be put in the documentation somewhere, or on the wiki.
> i'm +1 for the class to be distributed. my main concern was about the
> best way to do this sympathetically. 
> IMHO the real decisions needed are:
> 1 our jar distribution strategy (in particular, whether we ship the
> optional jar or not)
> 2 how we give downstream packagers and users a fair view of the actual
> JCL dependencies
> i'll move these two important and related issues to a separate thread.
>> * Decide whether to merge the weak-hash-map stuff into the main trunk or
>> leave it in an "optional" jar. If we merge it, we can do away with the
>> optional jar completely which is good. However it does mean that if
>> there is a bug in it people can't disable it. If bundled in the main jar
>> there might need to be a little extra code to just ignore it when it
>> throws an exception on load for java < 1.3.
> this is a tough call :-/
> but probably want to add that code in any case
> i'm learning towards distributing a more limited number of more easily
> understood standard jars (more on this in the other thread). probably
> need to work through the shape of the distribution first.
>> * 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.

> 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 
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?

>> * Consider Joerg Schaible/Joerg Hohwiller's "getChildLogger" proposal.
>> I'm tempted not to include this, though. Getting a release out is
>> probably the highest priority.
> IMHO i need to be certain that everything's exactly right before i'm
> willing to commit it. i was trying to work through the issues and making
> sure i understood them but this went a bit quiet.
> either of the two Joerg's around to advocate it's inclusion?
> - robert

Dennis Lundberg

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

View raw message