Return-Path: 
 <commons-dev-return-79610-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 63008 invoked from network); 12 Nov 2005 12:42:16 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 12 Nov 2005 12:42:16 -0000
Received: (qmail 28450 invoked by uid 500); 12 Nov 2005 12:42:14 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 28107 invoked by uid 500); 12 Nov 2005 12:42:13 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 28096 invoked by uid 99); 12 Nov 2005 12:42:13 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 12 Nov 2005 04:42:13 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of
 robertburrelldonkin@blueyonder.co.uk designates 195.188.213.4 as permitted
 sender)
Received: from [195.188.213.4] (HELO smtp-out1.blueyonder.co.uk)
 (195.188.213.4)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 12 Nov 2005 04:42:05 -0800
Received: from knossos.elmet ([82.38.65.173]) by smtp-out1.blueyonder.co.uk
 with Microsoft SMTPSVC(5.0.2195.6713);
	 Sat, 12 Nov 2005 12:42:43 +0000
Subject: Re: [logging] What's needed for a release
From: robert burrell donkin <robertburrelldonkin@blueyonder.co.uk>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <1131735900.4067.9.camel@localhost.localdomain>
References: <4370AD91.7040506@markproctor.com>
	 <5C588555-E352-4506-AEE1-8AF1FE85D810@apache.org>
	 <4370EC69.7060501@markproctor.com> <437179D4.5050905@apache.org>
	 <D43DBD11-1392-4F9A-895A-F92BEC4E79E8@apache.org>
	 <1131609883.3882.13.camel@localhost.localdomain>
	 <1131662448.5045.52.camel@knossos.elmet>
	 <1131735900.4067.9.camel@localhost.localdomain>
Content-Type: text/plain
Date: Sat, 12 Nov 2005 13:00:22 +0000
Message-Id: <1131800422.5037.59.camel@knossos.elmet>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.1-1mdk 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Nov 2005 12:42:43.0256 (UTC)
 FILETIME=[93487380:01C5E786]
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

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 :-/

opinions?

> * Verify that TRACE support works for log4j's latest releases.

+1

volunteers?

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


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