commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [logging] What's needed for a release
Date Sat, 12 Nov 2005 13:00:22 GMT
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


Mime
View raw message