You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by robert burrell donkin <ro...@blueyonder.co.uk> on 2005/02/07 23:16:42 UTC
[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-dev&m=110780577017737&w=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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] 1.0.5 release: plan update and bug review
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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-dev&m=110780577017737&w=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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] 1.0.5 release: plan update and bug review
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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-dev&m=110780577017737&w=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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] 1.0.5 release: plan update and bug review
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] 1.0.5 release: plan update and bug review
Posted by Richard Sitze <rs...@us.ibm.com>.
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 <ro...@blueyonder.co.uk> 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-dev&m=110780577017737&w=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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>