commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <>
Subject Re: [logging] 1.0.5 release: plan update and bug review
Date Tue, 08 Feb 2005 00:46:48 GMT
Just for the record, might as well get this out now :-)

I'm going to take a fairly STRONG position against fixing discovery in a 
1.0.6 if that is the ONLY change going in.  Why?

- The "fix" I envision will necessitate "backwards incompatible" behavior 
in a "standalone" commons-logging.jar file.  This requires more than a 
point release.

- commons-logging 2.0 should default to a simple discovery process very 
much in line with the UGLI discovery [typical J2SE configuration], and 
give up all attempts for managing complicated ClassLoader hierarchy 

- commons-logging 2.0 should to defer to commons-discovery, if 
commons-discovery is available in an appropriate class-loader [and yes, 
this means "discovering" commons-discovery... headache time.. but we'll 
keep it simple anyway :-)  right?].

- I want to "fix" the ClassLoader problems in commons-discovery.

- Specifically, allow the commons-logging 2.0 + commons-discover X.Y to 
function well under J2EE and OSGI environs... or any other complicated 
ClassLoader environment.

Now, all that aside, someone is going to argue that we should "go ahead" 
and fix the ClassLoader problems in 1.0.6.  All well and good, but note 
that I want to *encourage* use of the new branch, and let the old branch 
rest piecefully [did I say die?  I didn't say die... did I?].  If you want 
a "sophisticated" discovery mechanism in complicated ClassLoader environs, 
then defer to the new "pluggable" discovery mechanism and be ready to work 
in OSGI, J2EE, or whereever.  If you don't need it, then what comes in 
commons-logging.jar will be sufficient for simple J2SE applications.


Richard A. Sitze
IBM WebSphere WebServices Development

robert burrell donkin <> wrote on 
02/07/2005 04:16:42 PM:

> back up and running now :)
> i propose to take a branch for the 1.0.5 release as soon as the
> outstanding matters have been discussed. this will free up head for
> possible work either towards a 1.0.6 (with improved discovery) or a
> major revision.
> brian contributed the required documentation (many thanks) so all that i
> have on my list now is to work out which bugs will be addressed for this
> release. here's the analysed consensus from the wiki (thanks to dennis
> for his review). please feel free to jump in and disagree if
> appropriate. 
> in the event of no complaints, i propose to update bugzilla and take the
> 1.0.5 release branch some time after 2200GMT tomorrow (tuesday). anyone
> with a problem with this plan should jump in now... 
> - robert
> Open Bugs
> ---------
> Bug 28291 LATER
>      Classloader related, these issues will be addressed by later
> releases 
> Bug 30131 CLOSE
>      This is related to httpclient example code but Dennis posted a
> followup (with no response) and I've check the example code (which looks
> ok to me).
> Bug 30268 LATER
>      Needs architectural changes
> Bug 30632 CLOSE
>      See 30131
> Bug 32618 LATER
>     The new proposal by IBM. 
> Bug 32662 WONTFIX
>     See
> Bug 32691 LATER
>     General heading of improvements to API. (Needs a champion.)
> Bug 33347 LATER
>     API improvements. (Needs a champion.)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message