[
https://issues.apache.org/jira/browse/LOG4NET-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792594#comment-13792594
]
Dominik Psenner edited comment on LOG4NET-400 at 10/11/13 1:17 PM:
-------------------------------------------------------------------
https://github.com/apache/log4net/blob/trunk/src/Repository/Hierarchy/Logger.cs
This is not the interface, but the concrete implementation of the interface.
The interface does not make an assumption on how the implementation works. Thus
the following:
{code}if(log.IsDebugEnabled)
log.Debug("this is my message"){code}
is now reduced to:
{code}log.DebugExt("this is my message"){code}
{quote}Why not just porting CommonLogging implementation into Log4Net?{quote}
Because DebugExt(Func<object> arg) allows to bypass the message construction of
custom objects which can then be processed by object renderers. To bypass the
string.Format one can already use the *Format() methods which are referenced by
the extension methods *FormatExt(). Thus writing:
{code}log.DebugExt(() => string.Format("my message {0}", "formatted"));{code}
is equivalent to the one below, where the latter preserves several stack
operations:
{code}log.DebugFormatExt("my message {0}", "formatted");{code}
Maybe we throw away the DebugFormatExt methods in a future release that breaks
backwards compatibility, but not this time.
was (Author: nachbarslumpi):
https://github.com/apache/log4net/blob/trunk/src/Repository/Hierarchy/Logger.cs
This is not the interface, but the concrete implementation of the interface.
The interface does not make an assumption on how the implementation works. Thus
the following:
{code}if(log.IsDebugEnabled)
log.Debug("this is my message"){code}
is now reduced to:
{code}log.DebugExt("this is my message"){code}
{quote}Why not just porting CommonLogging implementation into Log4Net?{quote}
Because DebugExt(Func<object> arg) allows to bypass the message construction of
custom objects which can then be processed by object renderers. To bypass the
string.Format one can already use the *Format() methods which are referenced by
the extension methods *FormatExt(). Thus writing:
{code}log.DebugExt(() => string.Format("my message {0}", "formatted"));{code}
is equivalent to:
{code}log.DebugFormatExt("my message {0}", "formatted");{code}
Maybe we throw away the DebugFormatExt methods in a future release that breaks
backwards compatibility, but not this time.
> ILog extension methods doesnt work as expected
> ----------------------------------------------
>
> Key: LOG4NET-400
> URL: https://issues.apache.org/jira/browse/LOG4NET-400
> Project: Log4net
> Issue Type: Improvement
> Reporter: Gian Marco Gherardi
>
> Hi, I'm trying the feature LOG4NET-290, but seems that the following format
> doesn't work:
> log.Debug( m=>m("value= {0}", obj.Value) );
> Instead this seems the correct signature:
> log.Debug(() => string.Format("value= {0}", obj.Value));
> That is not as convenient IMO. Another thing I've noticed is that there are
> also many extension methods that merely proxy the methods already supported
> by plain ILog. What's the reason for that? I mean ILog methods already skip
> logging if level is not active.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
