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