Re: [logging] 1.0.5 release: plan update and bug review
On Tue, 2005-02-08 at 00:46, Richard Sitze wrote:
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.
note that i said 'improve' not fix :)
now that i understand the issues more clearly, i think that it would be
possible to improve the classloader related behaviour of the 1.0.x
series of releases but this would not be a fix (in the wider sense) for
discovery. it wouldn't be unreasonable to create a JCL 1.0.6 release
along those lines provided that there were volunteers willing to carry
out the work.
Why?
- The fix I envision will necessitate backwards incompatible behavior
in a standalone commons-logging.jar file. This requires more than a
point release.
i've been thinking along similar lines for a while but i think that it's
probably possible to maintain a large measure of backwards
compatibility. IMHO the measure of backwards compatibility will go a
long way to determining the rate of adoption.
however, i would definitely agree that any radical change of
architecture should be 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
problems.
i favour a minimal API layer with no symbolic coupling downwards. i'd
prefer to use just a system property for configuration: even loading a
resource file can sometimes be a little interesting.
i agree that all classloading discovery should be delegated to an
implementation loaded by name.
- commons-logging 2.0 should to defer to commons-discovery, if
commons-discovery is available in an appropriate class-loader
i've always wanted an alternative mechanism based on commons-discovery.
[and yes, this means discovering commons-discovery... headache time.. but
we'll
keep it simple anyway :-) right?].
i'd prefer to side step this particular can-of-worms and i think that
it's possible to do so. i'd like to see the configuration of the basic
discovery mechanism separated from the execution of that mechanism.
though JCL needs to run in a variety of environments with differing
discovery mechanisms, for each environment the basic discovery mechanism
can (and should) be constant.
JCL could provide some defaults probably something similar to the
current LogFactory ('classic') and a commons-discovery adapter. by
making the (not unreasonable) insistance that an appropriate set of
classes (JCL API plus discovery mechanism) is deployed together in the
same classloader, it should be possible to use the classloader to load
the discovery implementation by name.
- I want to fix the ClassLoader problems in commons-discovery.
+1
- 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.
+1
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.
if people want to continue refining the 1.0.x series of releases, that's
cool. following the best apache traditions
(http://incubator.apache.org/learn/rules-for-revolutionaries.html),
providing that there are developers willing to develop and reasons to
code, there's no reason why the birth of a new branch should mean the
death of the other.
users have their own reasons for choosing one open source product over
another: some good, some bad. IMHO the merits of the new stuff will turn
out be pretty clear. it's far better to be positive about the merits of
the new than focusing on the drawbacks of the old.
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.0.5 release: plan update and bug review
since there have been no objections (at least to the 1.0.5 release), i'm going to start work on the plan now. - robert On Mon, 2005-02-07 at 22:16, robert burrell donkin wrote: 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 http://issues.apache.org/bugzilla/show_bug.cgi?id=28291 Classloader related, these issues will be addressed by later releases Bug 30131 CLOSE http://issues.apache.org/bugzilla/show_bug.cgi?id=30131 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 http://issues.apache.org/bugzilla/show_bug.cgi?id=30268 Needs architectural changes Bug 30632 CLOSE http://issues.apache.org/bugzilla/show_bug.cgi?id=30632 See 30131 Bug 32618 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=32618 The new proposal by IBM. Bug 32662 WONTFIX http://issues.apache.org/bugzilla/show_bug.cgi?id=32662 See http://marc.theaimsgroup.com/?l=jakarta-commons-devm=110780577017737w=2 Bug 32691 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=32691 General heading of improvements to API. (Needs a champion.) Bug 33347 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=33347 API improvements. (Needs a champion.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.0.5 release: plan update and bug review
release branch taken. next i'll be updating the trunk to JCL version 1.0.6-dev (just a name, not a decision ;) and rebuilding the website with news about the 1.0.5 release (unless someone beats me to it). then pushing towards a 1.0.5 release candidate. - robert On Tue, 2005-02-08 at 22:33, robert burrell donkin wrote: since there have been no objections (at least to the 1.0.5 release), i'm going to start work on the plan now. - robert On Mon, 2005-02-07 at 22:16, robert burrell donkin wrote: 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 http://issues.apache.org/bugzilla/show_bug.cgi?id=28291 Classloader related, these issues will be addressed by later releases Bug 30131 CLOSE http://issues.apache.org/bugzilla/show_bug.cgi?id=30131 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 http://issues.apache.org/bugzilla/show_bug.cgi?id=30268 Needs architectural changes Bug 30632 CLOSE http://issues.apache.org/bugzilla/show_bug.cgi?id=30632 See 30131 Bug 32618 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=32618 The new proposal by IBM. Bug 32662 WONTFIX http://issues.apache.org/bugzilla/show_bug.cgi?id=32662 See http://marc.theaimsgroup.com/?l=jakarta-commons-devm=110780577017737w=2 Bug 32691 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=32691 General heading of improvements to API. (Needs a champion.) Bug 33347 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=33347 API improvements. (Needs a champion.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] 1.0.5 release: plan update and bug review
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 http://issues.apache.org/bugzilla/show_bug.cgi?id=28291 Classloader related, these issues will be addressed by later releases Bug 30131 CLOSE http://issues.apache.org/bugzilla/show_bug.cgi?id=30131 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 http://issues.apache.org/bugzilla/show_bug.cgi?id=30268 Needs architectural changes Bug 30632 CLOSE http://issues.apache.org/bugzilla/show_bug.cgi?id=30632 See 30131 Bug 32618 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=32618 The new proposal by IBM. Bug 32662 WONTFIX http://issues.apache.org/bugzilla/show_bug.cgi?id=32662 See http://marc.theaimsgroup.com/?l=jakarta-commons-devm=110780577017737w=2 Bug 32691 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=32691 General heading of improvements to API. (Needs a champion.) Bug 33347 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=33347 API improvements. (Needs a champion.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.0.5 release: plan update and bug review
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 problems. - 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. ras *** Richard A. Sitze IBM WebSphere WebServices Development robert burrell donkin [EMAIL PROTECTED] 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 http://issues.apache.org/bugzilla/show_bug.cgi?id=28291 Classloader related, these issues will be addressed by later releases Bug 30131 CLOSE http://issues.apache.org/bugzilla/show_bug.cgi?id=30131 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 http://issues.apache.org/bugzilla/show_bug.cgi?id=30268 Needs architectural changes Bug 30632 CLOSE http://issues.apache.org/bugzilla/show_bug.cgi?id=30632 See 30131 Bug 32618 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=32618 The new proposal by IBM. Bug 32662 WONTFIX http://issues.apache.org/bugzilla/show_bug.cgi?id=32662 See http://marc.theaimsgroup.com/?l=jakarta-commons-devm=110780577017737w=2 Bug 32691 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=32691 General heading of improvements to API. (Needs a champion.) Bug 33347 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=33347 API improvements. (Needs a champion.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.0.5 release plan
On 31 Jan 2005, at 07:57, Brian Stansberry wrote: snip Attached is a patch that fixes this. it's best to attach patches to a bugzilla report since (i think) this list strips (most) attachments. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.0.5 release plan
On 29 Jan 2005, at 07:53, Brian Stansberry wrote: Hi Robert, Sorry to drop off the face of the earth -- my wife and I had a baby last month :) so . congratulations :) I'll have some time on Sunday and would be happy to help out with documentation if you'd like. that'd be great. my main development machine (G4 cube) blew at least a fan on Thursday and I've spent most of the weekend setting stuff up on a secondary machine and disassembling my cube. with the move to subversion coming as well, it may take me a while to catch up... Assuming you plan to format the Release Notes similarly to the 1.0.4 release, I can draft a couple paragraphs re: the change to LogFactory and the addition of WeakHashtable. if can update the user documentation, then it's probably easier for me to pull it out for the release notes. I was also thinking a note in the user guide similar to the class javadoc in WeakHashtable might be useful. Or anything else you think appropriate. something for the user guide similar to the class javadocs together with some notes about the distribution (dropping the optional jar into the classpath) would be great :) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.0.5 release plan
I'll have some time on Sunday and would be happy to help out with documentation if you'd like. Sorry, didn't get as much free time as I thought today; will get you some stuff tomorrow evening. I was building JCL with ant and couldn't get a commons-logging-optional.jar to build when executing the build.xml in the root directory. Instead the optional classes would get included in commons-logging.jar. Looked into this and saw that the when the main build.xml called the build in the optional folder, it was passing along all its properties, thus overriding the optional version. Attached is a patch that fixes this. I was also thinking a note in the user guide similar to the class javadoc in WeakHashtable might be useful. Or anything else you think appropriate. something for the user guide similar to the class javadocs together with some notes about the distribution (dropping the optional jar into the classpath) would be great :) Will do :) Brian __ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] 1.0.5 release plan
Hi Robert, Sorry to drop off the face of the earth -- my wife and I had a baby last month :) so . I'll have some time on Sunday and would be happy to help out with documentation if you'd like. Assuming you plan to format the Release Notes similarly to the 1.0.4 release, I can draft a couple paragraphs re: the change to LogFactory and the addition of WeakHashtable. I was also thinking a note in the user guide similar to the class javadoc in WeakHashtable might be useful. Or anything else you think appropriate. Best, Brian --- robert burrell donkin [EMAIL PROTECTED] wrote: the consensus seems to be that a 1.0.5 release is a good thing and that people are happy with me acting as release manager. the release plan can be found here: http://wiki.apache.org/jakarta-commons/Logging/1_2e0_2e5ReleasePlan it's good to see that people have already started work (thanks denis :) please feel free to dive in! comments are especially useful for the bugs parade. it'd probably be best for folks to attached their comments in a sub-list below each one. i'll prepare an proposal containing the analysis for the list a little later. i propose to start work on this release pretty much as soon as the repository has been converted to subversion. i'll add replies to this thread to keep people up to date... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] 1.0.5 release plan
the consensus seems to be that a 1.0.5 release is a good thing and that people are happy with me acting as release manager. the release plan can be found here: http://wiki.apache.org/jakarta-commons/Logging/1_2e0_2e5ReleasePlan it's good to see that people have already started work (thanks denis :) please feel free to dive in! comments are especially useful for the bugs parade. it'd probably be best for folks to attached their comments in a sub-list below each one. i'll prepare an proposal containing the analysis for the list a little later. i propose to start work on this release pretty much as soon as the repository has been converted to subversion. i'll add replies to this thread to keep people up to date... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
