.NET Core: Lowering the log level of 3rd party components

With the new .NET Core framework and libraries we have got an interface called Microsoft.Extensions.Logging.ILogger to be used for writing log messages. Various 3rd party and built-in components make very good use of it. To see how much is being logged just create a simple Web API using Entity Framework (EF) and the Kestrel server and in a few minutes you will get thousands of log messages.

The downside of such a well-known interface is that the log level chosen by the 3rd party developers may be unfitting for the software using it. For example, Entity Framework uses the log level Information for logging generated SQL queries. For the EF developers it is a good choice because the SQL query is an important information for them - but for our customers using EF this information is for debugging purposes only.

Luckily it is very easy to change the log level of a specific logging source (EF, Kestrel etc.). For that we need a simple proxy that implements the interface ILogger. The proxy is changing the log level to Debug in the methods Log and IsEnabled and calls the corresponding method of the real logger with new parameters.

public class LoggerProxy : ILogger
{
	private readonly ILogger _logger;

	public LoggerProxy(ILogger logger)
	{
		if (logger == null)
			throw new ArgumentNullException(nameof(logger));

		_logger = logger;
	}

	public void Log(LogLevel logLevel, int eventId, object state, 
		Exception exception, Func<object, Exception, string> formatter)
	{
		if (logLevel > LogLevel.Debug)
			logLevel = LogLevel.Debug;

		_logger.Log(logLevel, eventId, state, exception, formatter);
	}

	public bool IsEnabled(LogLevel logLevel)
	{
		if (logLevel > LogLevel.Debug)
			logLevel = LogLevel.Debug;

		return _logger.IsEnabled(logLevel);
	}

	public IDisposable BeginScopeImpl(object state)
	{
		return _logger.BeginScopeImpl(state);
	}
}

To inject the LoggerProxy we have to create another proxy that implements the interface Microsoft.Extensions.Logging.ILoggerFactory. The method we are interested in is CreateLogger that gets the category name as a parameter. The category name may be the name of the class requesting the logger or the name of the assembly. In this method we make the real logger factory create a logger for us and if this logger is for Entity Framework we return our LoggerProxy wrapping the real logger.

public class LoggerFactoryProxy : ILoggerFactory
{
	private readonly ILoggerFactory _loggerFactory;
	
	public LogLevel MinimumLevel
	{
		get { return _loggerFactory.MinimumLevel; }
		set { _loggerFactory.MinimumLevel = value; }
	}

	public LoggerFactoryProxy(ILoggerFactory loggerFactory)
	{
		if (loggerFactory == null)
			throw new ArgumentNullException(nameof(loggerFactory));

		_loggerFactory = loggerFactory;
        }

	public ILogger CreateLogger(string categoryName)
	{
		var logger = _loggerFactory.CreateLogger(categoryName);

		if (categoryName.StartsWith("Microsoft.Data.Entity.", StringComparison.OrdinalIgnoreCase))
			logger = new LoggerProxy(logger);

		return logger;
        }

	public void AddProvider(ILoggerProvider provider)
	{
		_loggerFactory.AddProvider(provider);
	}

	public void Dispose()
        {
		_loggerFactory.Dispose();
	}
}

Finally, we need to register the factory proxy with the dependency injection container.

public void ConfigureServices(IServiceCollection services)
{
	var factory = new LoggerFactoryProxy(new LoggerFactory());
	services.AddInstance(factory);
}

For now on the log messages coming from Entity Framework will be logged with the log level Debug.


AngularJS: Dynamic Directives

In this post, we will look into an approach for exchanging the definition of an AngularJS directive, i.e. the template, controller, compile/link functions etc., after the application has been bootstrapped whereby carrying out a full reload is not an option.

Assume that you have an application that allows the user to have multiple accounts to switch between. Depending on the currently active account, the application establishes a connection to different servers that in turn have different definitions for the same AngularJS directive.

Here is a simplified example:

<!-- the user is not logged in => show nothing (or some default content) -->
<my-directive message="'Hello World'" />

---------------------------------------------------------------------------------

<!-- the user is connected to “server A” => fetch and apply the directive definition delivered by “server A” 
{
	restrict: 'E',
	template: '<div>Coming from Server A</div>'
};
-->
<my-directive>
	<div>Coming from the Server A</div>
</my-directive>

---------------------------------------------------------------------------------

<!-- the user is connected to “server B” => fetch and apply the directive delivered by “server B”
{
	restrict: 'E',
	scope: {
		message: '='
	},
	template: '<span>And now from Server B: {{message}}</span>'
};
-->
<my-directive>
	<span>And now from Server B: Hello World</span>
</my-directive>

To be able to exchange the entire definition of an AngularJS directive after the application has started we need to address the following problems:

  • Lazy loading
  • Directive definition exchange
  • On-demand recompilation

Let’s have a look at each point in more detail now.

1) Lazy loading

Problem: The usual way to register a directive does not work after the application has bootstrapped.

// the usual way to register a directive
angular.module('app').directive('myDirective', MyDirective);

For the registration of an AngularJS directive after the application has started, we need the $compileProvider. We can get a hold of the $compileProvider during the configuration phase, and save the reference somewhere we get access to later, like in a service (in our example it will be the dynamicDirectiveManager).

// grab the $compileProvider
angular.module('app')
	.config(function ($compileProvider, dynamicDirectiveManagerProvider) {
		dynamicDirectiveManagerProvider.setCompileProvider($compileProvider);
	});

// Later on, we are able to register new directives using the $compileProvider
$compileProvider.directive.apply(null, [name, constructor]);

By using the $compileProvider we are now able to lazy-load directives.

2) Directive definition exchange

Problem: Re-registering a directive using the same name but different definition (i.e. template, controller, etc.) does not work.

$compileProvider.directive
	.apply(null, [ 'myDirective', function() { return { template: 'Template A', … } } ]);

// … some time later …
$compileProvider.directive
	.apply(null, [ 'myDirective', function() { return { template: 'Other template', … } } ]); 
// the previous statement won’t overwrite the directive

Due to caching in AngularJS, the directives that we are trying to overwrite are not going to be exchanged by a new one. To remedy this problem, we have no other choice but to change the name in some way, for example by appending a suffix. Luckily, we can hide this renaming in the previously mentioned dynamicDirectiveManager.

// will compile to <my-directive-optionalsuffix>
dynamicDirectiveManager.registerDirective('myDirective', function() { return { template: 'Template', … } }, 'optionalsuffix');

// … some time later …
// will compile to <my-directive-randomsuffix>
dynamicDirectiveManager.registerDirective('myDirective', function() { return { template: 'Other template', … } });

3) On-demand recompilation

Problem: Now, we are able to exchange a directive definition by a new one but the corresponding directives on our HTML page will not recompile themselves, especially if the directives (except for markup in the page) did not exist at all a moment ago.

To be able to recompile the directives on demand, the desired directive will be created by another one (say <dynamic-directive>) that we have full control over. That way we can call $compile() every time a directive has been overwritten.

<!-- Remark: the attribute “message” has no meaning for the <dynamic-directive> but for <my-directive> -->

<!-- dynamic directive … -->
<dynamic-directive element-name="my-directive" message="'Hello World'"></dynamic-directive>
<!-- or -->
<dynamic-directive element-name="{{getDirectiveName()}}" message="'Hello World'"></dynamic-directive>

<!-- … will initially compile into something like … -->
<dynamic-directive element-name="my-directive" message="'Hello World'">
	<my-directive message="'Hello World'" />
</dynamic-directive>

<!-- … and after a registration of a new directive definition … -->
<dynamic-directive element-name="my-directive" message="'Hello World'">
	<my-directive-someprefix message="'Hello World'" />
</dynamic-directive>

<!-- from now on, the <my-directive> is on its own, at least until the next exchange of the directive definition … -->

By using the $compile service, we solved one problem but created a memory leak. If the inner directive (<my-directive>) requests an isolated or child scope, then we get a deserted scope on each recompile thereby slowing the whole application bit by bit.

To solve this issue, we need to check whether the scope of the inner directive is different than the scope of the <dynamic-directive>. If so, then the inner scope will be disposed of by calling $destroy().

var innerScope = currentInnerElement.isolateScope() || currentInnerElement.scope();

if (innerScope && (innerScope !== scope)) {
	innerScope.$destroy();
}

Voilà!

Conclusion

This is a quite special case and it requires quite some code just to overwrite a directive without restarting the application. Luckily, the bulk of the work is done either by the <dynamic-directive> or by dynamicDirectiveManager.

Live working example

http://jsfiddle.net/Pawel_Gerr/y22ZK/