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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
