On 12/6/2008 6:27 AM, Thorbjørn Ravn Andersen wrote:
> 
> I believe that the positive in decoupling the logging implementation
> from the application will vastly overshadow any inconvinience in this
> regard.  Most if not all of the work has been done in the slf4j project.

Right.  "Most if not all the work has been done".  What is left?  SLF4J has
succeeded in its aim.  Congratulations!  And I'm not being facetious here.  So,
what exactly is the impetus to to modify Log4j 1.2 when existing SLF4J binders
work well with it?

Also, it seems to me that there is a clear advantage to the SLF4J project in
maintaining control of its own development.  If there's some fundamental fix 
that
needs to be done to all binders it can be done and released quickly; entirely
under the control of one project.  Why move part of this control out to external
projects?  What is the advantage of it?  Wouldn't that necessitate Log4j to
coordinate its release cycles with SLF4J to a certain extent?  Such a burden 
seems
totally unnecessary as they can and have lived happily apart up to now.

> 
>> However, I could see a significant political advantage to SLF4J to
>> have an implicit endorsement from the ASF and in my mind that is what
>> this proposal is about.  In my mind, java.util.logging has already won
>> the API standardization war years ago, but it has been mostly limited
>> the available appenders and configurators.  One of the design goals
>> (https://issues.apache.org/jira/browse/LOG4J2-5) for log4j 2.0 is to
>> have the back-end classes independent of the API, so that the bulk of
>> log4j 2 is isolated from the client's API choice.
> I find your statement quite interesting.
> 
> If j.u.l won the standardization war, then how come that there has been
> no adapter from log4j to j.u.l from this project?  That would be the
> perfect way to migrate to a standards based logging solution.
> 

I'm not sure about this whole "JUL has won the API war" thing?  I guess I'd have
to hear more from Curt about why he believes this?  I've never even considered
using JUL, but maybe that's just me?

However, the question of why Log4j has not provided adapters for JUL in the 
1.2.xx
codebase is probably because it's somewhat of a dead end, development-wise.  It 
is
in maintenance mode.  It generally works well, but there are fundamental issues
(threading) that can't be fixed without breaking compatibility.  So, changes are
limited to those that preserve compatibility.  The upside is that existing users
who have written custom extensions can upgrade and pick up fixes without having 
to
worry about breakage.  The downside is that the motivation to innovate remains 
in
hibernation until someone gets cracking on Log4j 2.0.  I, for one, seem to have
less and less time for this as the years go by; sad but true.

> Are you *ABSOLUTELY* certain you want to bring in politics in this
> technical issue?  In my opinion it will only mudden the waters!
> 

I don't necessarily condone it, but I understand where it comes from.  And 
unless
you followed Log4j-1.3/nLog4j/UGLI experience a few years back, you probably 
won't
understand.  All I can say is that there's a bit of Dejavu going on here.

BTW, notice that Curt did not say no.  He said he wants to evaluate the 
proposal.
 I think that's reasonable and that demanding immediate consensus is not.  I'd
also like to hear some more convincing arguments from the SLF4J side about how
this proposal provides real benefits over what exists today?  See my questions
above for more on that.

Finally, let's not get lost in tangential issues and concentrate our attention 
on
the original proposal...

"I propose that log4j implement the SLF4J API directly. This can be done in the
next version of log4j, say 1.3 or 2.0."

I think consensus may be quite high if we're talking about Log4j 2.0, as it has
already been planned that 2.0 will not be compatible with 1.2.xx.  Though keep 
in
mind that some have certain [re]designs in mind for 2.0.  If Ceki's conception 
of
2.0 is simply 1.2.xx implementing the SLFJ, I'm not sure he will gain much
traction?  And, again, a convincing argument must be (and hasn't been) made as 
to
the benefit of direct extension -vs- the existing model.


Jake

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to