logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Direct SLF4J implementation in log4j (was Re: Experimental log4j formatter in sandbox)
Date Thu, 12 Jan 2006 23:28:05 GMT

On Jan 12, 2006, at 9:47 AM, Ceki Gülcü wrote:

> Unfortunately, SLF4J support was recently removed. I
> would like to see it restored. I can personally vouch that keeping
> NLOG4J in sync with SLF4J is almost effortless, especially since the
> SLF4J is now quite stable. Unless there is opposition, I'd like to
> take the initiative to restore native SLF4J support in 1.3.

At the moment, the focus is on restoring binary compatibility with  
log4j 1.2 and adding SLF4J direct implementation would seem to at  
least complicate that.  So I would oppose committing anything on the  
trunk at this time.

I would love to see any analysis of the performance penalty due to  
using a SLF4J wrapper implementation instead of an SLF4J direct  
implementation.  If there is a substantial performance penalty for  
the wrapper approach, would there be other ways of reducing the  
penalty instead of a direct implementation.

The wrapper approach definitely has packaging benefits as it

a) eliminates a mandatory dependency and need to distribute and place  
on the class path an SLF4J jar even if not using SLF4J
b) an allows log4j and SLF4J to evolve independently and to mix and  
match versions of SLF4J and log4j.

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

View raw message