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]
