Small hint from NLog developer:

Why don't you pass the raw message with parameter placeholders, format arguments and IFormatProvider down to the logging engine and defer calling the actual String.Format to as late as possible?

This way you can avoid the cost of String.Format() at all if there are filters (or whatever) which cause the message to be ignored, while IsXXXEnabled would return true.

One thing that you need to be aware of is the possible reentrancy problem, since format arguments may be objects which override ToString() and which do the logging inside this method. Things can get weird if you call logging code in the middle of logging (mostly because of locking and thread-locality issues), but this is something that can be quite easily sorted out.

I'm not sure if this can be easily done in log4net, though.

Regards,
--
Jarek
http://www.nlog-project.org/ - a log4net alternative

----- Original Message ----- From: "Nicko Cadell" <[EMAIL PROTECTED]>
To: "Log4NET Dev" <log4net-dev@logging.apache.org>
Sent: Sunday, March 19, 2006 2:17 AM
Subject: RE: Logging formatter in log4j sandbox


The .NET String.Format syntax looks similar to the MessageFormat syntax.
A syntax guide is here:
http://msdn.microsoft.com/library/en-us/cpguide/html/cpconcompositeforma
tting.asp

Currently we have the format methods added directly to the Ilog
interface, however we haven't release code with this in. It would be
possible to move the format methods into a separate class of static
helper methods.

I think I should made the point that the String.Format syntax is
standard, it has been part of .net since the start and is understood and
expected by .net developers. I don't think that there are any
competitors (yet) to this format syntax in the .net world.

It will be very much more difficult to refactor the format functionality
after the release of 1.2.10 than before, however there are already a
number of users that are already using the functionality from their own
custom builds of the log4net source.

Nicko

-----Original Message-----
From: Curt Arnold [mailto:[EMAIL PROTECTED]
Sent: 19 March 2006 00:32
To: log4net-dev@logging.apache.org
Subject: Logging formatter in log4j sandbox

I'm sure the timing sucks, but since the scuttling of the
1.2.10 release involves formatting log messages and I have
recently been doing some things in the log4j sandbox, I
thought that I would bring that work to your attention.  The
project can be checked out from
http://svn.apache.org/repos/asf/logging/sandbox/log4j/formatter.

One of the problems with adding formatting to the Logger
class in log4j is that there are several widely used
formatting conventions:
java.text.MessageFormat has been in Java for quite some time,
java.util.Formatter was just added in JDK 1.5 (similar to C's
sprintf) and the UGLI/SLF4J effort added a syntax similar but
distinct to MessageFormat
(org.apache.log4j.helpers.MessageFormatter).  Currently the
log4j code uses both java.text.MessageFormat (in the l7dlog
methods) and o.a.l.helpers.MessageFormatter (in the
debug(String fmt, ...) methods.

The sandbox effort intention was to remove formatting from
the Logger class and to allow the user to pick the formatter
of their choice, while still being able to bypass argument
boxing, array creation and formatting on calls below the
threshold.  The formatter project adds three static classes
LogMF, LogSF and LogF which log using the
java.text.MessageFormat, UGLI/SLF4J formatter and
java.util.Formatter respectively.  In use the code would look like:

LogMF.debug(logger, "User {0} logged out after {1} seconds",
username, duration);

The original discussion can be read at http://marc.theaimsgroup.com/?
l=log4j-dev&m=113704872508753&w=2

I don't know the pattern syntax of the .NET formatter in use.
 If it is similar to one of the Java formatters, then I would
use the corresponding class name.  Otherwise, I would choose
a slightly different name in case we ever wanted to emulate
one of the Java formatters in .NET (actually, you might
already be able to use java.text.MessageFormat from J#).

p.s. I had intended to add ResourceBundle variants of the
methods with signatures like:

static void debug(Logger logger, ResourceBundle bundle,
String fmtKey, ...);






Reply via email to