You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Curt Arnold <ca...@apache.org> on 2005/08/02 22:43:23 UTC

slf4j-1.0-beta4 update

I'll try to commit an update tonight (barring objection) that will  
update the CVS HEAD to use slf4j-1.0-beta4 (currently uses beta3)  
when compiled using the -Dslf4j=true switch.  The major change is  
that messages and format specifiers have been changed from Object to  
String in  org.slf4j.Logger, for example:

debug(Object msg) -> debug(String msg)
debug(Object msg, Throwable t) -> debug(String msg, Throwable t)
debug(Object pattern, Object param1) -> debug(String pattern, Object  
param1)

and so on for error, info and warn.

The first two had been identical to existing methods on  
org.apache.log4j.Category.  Since the parameters could of the  
existing method can not be changed without breaking source and run- 
time compatibility with earlier versions of log4j, I added additional  
methods with the new signatures that delegate to the old methods,  
that is something like:

public void debug(final String msg) {
    debug((Object) msg);
}

I'm hoping that the JVM is smart enough to do that almost free, but  
haven't benchmarked it.   Delegating is the right thing to do since  
existing extensions of Logger may have overriden the old methods  
(they weren't declared final).  Unfortunately, if there is a hit, it  
will occur both in the slf4j enabled and normal log4j builds as it is  
current structured.

I had original implemented the new signatures as final, however that  
would cause XLogger to fail to compile since it had introduced its  
own debug(String msg) and making it final in the base class caused it  
to fail to compile.  Seems like a bad thing to do, but since it  
happened in the unit tests, I'm sure that it happens in the real  
world so I took the final designation off.

Eventually, I'd like to do benchmarking to understand the performance  
difference if any between a facade implementation and the current  
direct implementation.  But this will keep us in synch with slf4j for  
now.

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