Logging formatter in log4j sandbox

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" <nickoneoworks.com>
To: "Log4NET Dev" <log4net-devlogging.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:carnoldapache.org]
>> Sent: 19 March 2006 00:32
>> To: log4net-devlogging.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  logged out
after  seconds",
>> username, duration);
>>
>> The original discussion can be read at http://marc.theaimsgro
up.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, ...);
>>
>>
>>
>>
>