commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2
Date Fri, 25 Mar 2005 13:33:47 GMT
On Fri, 2005-03-25 at 09:16 +0100, Boris Unckel wrote:
> Hello Remy,
> > As a personal note, I find this proposal completely out of place after
> > years of FUDing and dissing commons-logging in general, and anything
> > not log4j in particular.
> This is not the intention of Yoav. To quote the discussion[1] as summary.
> "This Get rid of the "we vs them" and create a "we" atmosphere." - Niclas
> Hedhman last mail in log4j-developers in that thread.


when will people realise that there isn't any 'them' left?

i'm grateful that remy and craig occasionally drop in and provide
valuable insights when they can but if you look at the commit records,
i'm the only active committer left on JCL. i have a day job to hold
down, variable health and other projects to keep alive. 

it is very important to understand that the biggest problem with JCL is
the lack of developer community. this is partly the fault of myself but
it's also a function of the difficulty of the material. community
building is therefore now my priority. a healthy JCl (or it's
replacement) will arise naturally from a healthy community. to quote an
ancient maxim (was it coined by stefano?): it's easy to create good code
from an unhealthy codebase with a healthy community but the converse is
almost impossible.  

as soon as brian started helping development before christmas, we
started making progress with some of the longstanding issues. i have
hopes that when simon's up to speed, he'll make a real difference. if
torsten (and others) on the fringes start to become more active then
there really is a good chance of progress. 

so, what matters to me is community. 

if (hypothetically) an invitation were issued from logging to move JCL,
then my only concern would be community. if there are a lot of potential
JCL developers over in loggingland who are put off by the fact that JCL
is in the commons and the consensus in the current community was that
they were happy to work within logging then i would happy to go. i was
also genuine about my offer to propose karma for any logging committers
who want to work on JCL (or it's replacement) here or just influence
it's future direction. 
i'm a little confused about the relationship of this idea with the idea
of rebranding UGLI as JCL2. i see these as unrelated. 

there are enough members at to make this rebranding
happen (regardless of the opinions of those in this list). AFAIK ULGI is
also pretty complete. that there would be very little need for
contributions from the jakarta commons community. the logical outcome of
this particular proposal would be that the proposed JCL2 would become
UGLI and whatever development was needed would be done over in logging.
JCL1 maintenance would be done here. (there's certainly enough work to
do in that respect.)

whether rebranding UGLI as JCL2 would be wise is a different matter. 

i am aware of issues with UGLI but i've tried to stay positive with the
aim of improving JCL (rather than making life difficult for UGLI). i
like UGLI and think that there are applications which would definitely
benefit from it's use. ceki's analysis is also (in places) misleading
(mainly through selecting examples which happen not to support the
analysis he lays on top of them) but i've tried to work with him in a
positive fashion (off list). i am very aware of the complexity of the
subject and (now) about the poor documentation available. i really don't
want to start any kind of public mud slinging and trust that this
paragraph is taken in the intended spirit.

i am in the process of preparing a longer more general analysis and
demonstration inspired by ceki. i hope that this will demonstrate both
the current issues with JCL's discover mechanism and be useful in going
forward with some sort of JCL2.

static binding has been discussed before here and it's limitations are
known. dynamic binding offers better support for some use cases but is
difficult to implement in practice and cannot work in some use cases
that i'd like to support. 

i also understand remy's point: backwards compatibility is very
important. it is JCL's huge installation base that gives momentum. many
users will review the choice of logging system altogether when faced
with a binary incompatible upgrade and (i suspect) many will (like remy)
choose java.util.logging. i think that a measure of backwards
compatibility is necessary for adoption. 

i also feel that given the amount of effort that ceki (and others) have
spent demolishing the reputation of JCL, if it's brand only that matters
then maybe UGLI would be a better choice in any case.

personally speaking, i find working on JCL a difficult and often
thankless task. i'd be grateful if logging offered to take away all my
JCL pain. however, i do feel an obligation to downstream users (such as
remy). i feel duty bound to act in their best interests. i am
unconvinced that simply renaming UGLI to JCL2 would be in their best
interests (or indeed anyone's) but (as i said previously) the JCL
developers are not in any real position to either help or hinder any
move to rebrand UGLI.

FWIW i've been an advocate of static binding for some time (where i
differ with ceki is that i prefer byte code engineering) but am aware of
use cases currently covered by dynamic discovery which cannot be covered
by static binding. i am also very aware that commons-discovery has a
better discovery implementation. therefore, i advocate a mixed approach
sharing a basic common interface. though LogFactory cannot be used as
is, it would be possible to lift a logical interface as an abstract

but this really isn't the time for design discussions

however, i would say that it is really the community
that needs to take the initiative. there really isn't the energy here to
spearhead any major change.

if the logging pmc thinks that matters would be more productively
managed by moving JCL to logging, then let's resolve that. there really
isn't any need to make any conditions. once we've built a bigger and
healthier community, let's see what code emerges.

alternative, if the logging pmc feels that they need to rebrand UGLI as
JCl2 then there really isn't anything to be gained by moving JCL1 to
logging. create a proposal and submit it to the jakarta pmc. 

- robert 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message