logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carl Raymond (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LOG4NET-326) Add a null logger implementation
Date Fri, 16 Mar 2012 22:04:43 GMT

     [ https://issues.apache.org/jira/browse/LOG4NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Carl Raymond updated LOG4NET-326:
---------------------------------

    Description: 
Please consider adding a null logger implementation to log4net.  This would be an implementation
of ILog where all logging method do nothing and all IsXxxEnabled methods return false.  This
supports Dependency Injection and unit testing patterns.  By providing a do-nothing implementation
of ILog, it is easier to move creation of a real logger via LogManager.GetLogger(...) outside
of the logging class, and into the DI container configuration.  Because this class is inherently
thread-safe, a singleton is appropriate.  Note that this class would never be returned by
LogManager.GetLogger().  It exists to serve as a default value for a read/write property of
type ILog.

Use case: A client project with class Thing that (optionally) logs has a property of type
ILog, where the default value of the property is the null logger.  The property can be set
to another logger by the DI container in production, or set to a mock ILog by a testing framework.

Code:
public class Thing
{
private ILog _myLogger = log4net.NullLogger.Instance;
public ILog MyLogger
	{
		get { return _myLogger; }
		set { _myLogger = value; }
	}

public SomeMethod()
	{
		// do some work...
		MyLogger.Info("message");
	}
}

The advantage of using a null logger as the property's default value is that the logging class
does not need to wrap all calls to the logger with null checks.

In a unit testing situation, it is not necessary to activate log4net at all.  When the test
at hand tests logging behavior, the test code would set the property to a mock ILog implementation,
which would then verify that the appropriate method was called.  Other tests not involving
logging do not need to set a value on the property.



  was:
Please consider adding a null logger implementation to log4net.  This would be an implementation
of ILog where all logging method do nothing and all IsXxxEnabled methods return false.  This
supports Dependency Injection and unit testing patterns.  By providing a do-nothing implementation
of ILog, it is easier to move creation of a real logger via LogManager.GetLogger(...) outside
of the logging class, and into the DI container configuration.  Because this class is inherently
thread-safe, a singleton is appropriate.  Note that this class would never be returned by
LogManager.GetLogger().  It exists to serve as a default value for a read/write property of
type ILog.

Use case: A client project with class Thing that (optionally) logs has a property of type
ILog, where the default value of the property is the null logger.  The property can be set
to another logger by the DI container in production, or set to a mock ILog by a testing framework.

Code:
public class Thing
{
private ILog _myLogger = log4net.NullLogger.Instance;
public ILog MyLogger
	{
		get { return _messageLogger; }
		set { _messageLogger = value; }
	}

public SomeMethod()
	{
		// do some work...
		MyLogger.Info("message");
	}
}

The advantage of using a null logger as the property's default value is that the logging class
does not need to wrap all calls to the logger with null checks.

In a unit testing situation, it is not necessary to activate log4net at all.  When the test
at hand tests logging behavior, the test code would set the property to a mock ILog implementation,
which would then verify that the appropriate method was called.  Other tests not involving
logging do not need to set a value on the property.



    
> Add a null logger implementation
> --------------------------------
>
>                 Key: LOG4NET-326
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-326
>             Project: Log4net
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Carl Raymond
>            Priority: Minor
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Please consider adding a null logger implementation to log4net.  This would be an implementation
of ILog where all logging method do nothing and all IsXxxEnabled methods return false.  This
supports Dependency Injection and unit testing patterns.  By providing a do-nothing implementation
of ILog, it is easier to move creation of a real logger via LogManager.GetLogger(...) outside
of the logging class, and into the DI container configuration.  Because this class is inherently
thread-safe, a singleton is appropriate.  Note that this class would never be returned by
LogManager.GetLogger().  It exists to serve as a default value for a read/write property of
type ILog.
> Use case: A client project with class Thing that (optionally) logs has a property of
type ILog, where the default value of the property is the null logger.  The property can be
set to another logger by the DI container in production, or set to a mock ILog by a testing
framework.
> Code:
> public class Thing
> {
> private ILog _myLogger = log4net.NullLogger.Instance;
> public ILog MyLogger
> 	{
> 		get { return _myLogger; }
> 		set { _myLogger = value; }
> 	}
> public SomeMethod()
> 	{
> 		// do some work...
> 		MyLogger.Info("message");
> 	}
> }
> The advantage of using a null logger as the property's default value is that the logging
class does not need to wrap all calls to the logger with null checks.
> In a unit testing situation, it is not necessary to activate log4net at all.  When the
test at hand tests logging behavior, the test code would set the property to a mock ILog implementation,
which would then verify that the appropriate method was called.  Other tests not involving
logging do not need to set a value on the property.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message