[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log4net-dev
Subject:    [jira] [Comment Edited] (LOG4NET-400) ILog extension methods doesnt work as expected
From:       "Dominik Psenner (JIRA)" <jira () apache ! org>
Date:       2013-10-11 13:18:42
Message-ID: JIRA.12673385.1381476689792.51469.1381497522612 () arcas
[Download RAW message or body]


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


[prev in list] [next in list] [prev in thread] [next in thread]