You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by "Carl Raymond (Updated) (JIRA)" <ji...@apache.org> on 2012/03/16 23:04:43 UTC

[jira] [Updated] (LOG4NET-326) Add a null logger implementation

     [ 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