logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject Re: [PROPOSAL] Implementing the SLF4J API directly
Date Fri, 05 Dec 2008 05:30:02 GMT
Hi Ceki,

On 12/4/2008 2:33 PM, Ceki Gulcu wrote:
> The point here is not comparing implementations but to have API
> convergence. It is less a technical matter (there not an ounce of
> doubt that it can be done with good results) than a question of
> collective will of log4j committers and log4j users.
> 

But what exactly is the advantage of implementing the SLF4J API rather than simply
placing slf4j-log4j.jar in the classpath?  The primary one I can see is that Log4j
repository selectors will work even when using the SLF4J API.  But I think we're
already in agreement that they aren't the panacea to logging separation we thought
they were a few years back.  So, that's hardly a relevant argument for the move.
Why introduce change to fix something that isn't broken?  The only psuedo-tangible
argument you make is that implementing the SLF4J API directly will provide "API
convergence".  But that's what SLF4J already provides today, no?

I think many of us rightly balked at implementing the UGLI API, which resulted in
the timultuous experiment called nLog4j.  You now admit that our argument was
"reasonable" back then, even though you clearly felt it was unreasonable at the
time as evidenced by the fact that you forked Log4j and mostly ceased contributing
to the original project you founded.  You now imply, once again, that those
opposed to your proposal are unreasonable.  Hmmm....

I've not yet made up my mind on the issue, but contrary to your certainty that
what you propose can do nothing but good, there are several reasons not to do it...

1.  The existing soluton of simply placing slf4j-log4j.jar in the classpath works
just fine.  You can't argue that it's just too many jars.  First, they're of
SLF4J's own creation (granted, by necessity).  Second, most apps already need 10's
of jars to run.  What's one more?

2.  Apache licensing and process issues

3.  Time and effort in performing the work, maintaining it, and supporting it...
or just even considering it for that matter.  I've already taken time away from
doing other things to respond to this proposal.  That's not to say you shouldn't
have made the proposal, but the commitment of peoples time to consider it can't be
overlooked.

4.  The introduction of any new code brings with it the risk of breakage of the
existing code.

I'm sure others can think of more.  Again, this is not to say it shouldn't be
done, but it's clearly not the slam-dunk you claim.

> Curt has plainly expressed his feelings. What do others think?

Curt has been an excellent steward of Log4j for a number of years now and I'm
disappointed to see his opinions discounted out of hand.  He's always taken a
conservative approach to changes in Log4j.  For the most part, I think that
approach has served the Log4j community well.  Why does it need to be "released
within days"?  Why not give Curt time to try things out?  Any testing will bear
out your assertion that it's "less a technical matter".  If you wish to gain
support of the "collective will of the Log4j committers and Log4j users", then let
those willing kick the tires report results and give everyone the time and
evidence they need to make an informed decision.


Jake

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message