logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: will there be a parameterized message in log4j like it is in slf4j?
Date Sun, 04 Oct 2009 04:07:44 GMT

On Oct 3, 2009, at 2:44 AM, leif wrote:

> hi there!
>
> do you plan to "backport" the parameterized message feature of slf4j  
> to log4j?
> we are using log4j and a switch to slf4j seems unneeded. just this  
> little
> feature for faster not logging sounds great:
>
> logger.debug("Entry number: {} is {}.", i, entry[i]);
>
> we know that there is a workaround, but that is not that expressive/ 
> short:
>
> if(logger.isDebugEnabled()) {
>  logger.debug("Entry number: " + i + " is " + entry[i]);
> }
>
> regards, leif


Scott Deboy wrote: (somehow did not hit my mail client, will need to  
figure out what is going on)
>
> I agree, logmf is not a good option, this feature needs to be in the  
> core logging framework.
>

Did I miss a message in the thread on LogSF/LogMF?  I've can think of  
two issues: it is not in the core distribution and Ceki had a  
benchmark where it compared unfavorably with SLF4J.  I never dug into  
the benchmark to find out what it might be hitting, but I can think of  
no fundamental reason why LogSF or LogMF should be noticeably slower  
in typical use.  I can see how using LogMF with some formats may  
trigger Locale sensitive formatting which may come with a cost.

For Leif's problem, the equivalent with LogSF is:

LogSF.debug(logger, "Entry number: {} is {}", i, entry[i]);

As far as I can tell, there is no way to remain compatible and also  
add the log4j 1.3 or slf4j signatures to org.apache.log4j.Logger.   
LogSF and LogMF were the best I could come up with.  Maybe not as  
natural as log4j 1.3's approach, but it kept compatibility and would  
work with earlier


> I think that leaves us with the option of adding useful features to  
> the current 1.2 codebase, even if it affects backward  
> compatibility.  Time for the log4j committers & interested users to  
> voice their opinions on 'the future of log4j'.

We can add useful features to log4j 1.2 as long as we don't break  
compatibility, however we would be doing a huge disservice to our  
existing client base by doing a maintenance release (especially with a  
minor version in the teens) that caused apps that have been using  
log4j 1.2 for a long time to break on upgrade.

If we decide to break, we should call it log4j 2.0, but we should  
really ensure that we can't solve the problem if we are going to do a  
minor break.


>
> As for Antonio's patches, thanks for providing them.  I've applied  
> them to my working copy and I'll commit them if everything goes ok.
>
> Scott
>

See note on commit.

---------------------------------------------------------------------
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