[RFC] Logging abstraction

[MopsiMauser]

Hello,

First of all I want to say thanks for this great library. I also have a feature request for better integration of this library into existing applications/libraries.

Is your feature request related to a problem? Please describe. EmbedIO uses its own logging implementation making it harder to integrate into existing apllications/libraries.

Describe the solution you'd like It would be easier for other application/libraries to integrate EmbedIO when it would support the ILoggerFactory interface, especially for .Net Core application.

[rdeago]

Hello @MopsiMauser, thanks for using EmbedIO!

Your proposal has its merits; however, as I'm sure you understand, the implementation is anything but straightforward. I'm pinning this issue and assigning it to the "x.0.0" - a.k.a. "maybe some time in the future" - milestone.

Some quick notes to future reviewers of said milestone:

• should both EmbedIO and SWAN use Microsoft.Extensions.Logging.Abstractions, and SWAN contain an implementation of ILoggerFactory?
• should logging be detached from SWAN into its own Swan.Logging library, so it doesn't weigh on installations that do not use it?
• do other logging abstractions exist of which we should be aware, maybe deserving more attention than Microsoft.Extensions.Logging.Abstractions?
• is EmbedIO's use case for logging sufficiently simple, that we can create an internal abstraction (a simple, abstract logging callback in WebServerBase, for example) so everybody can use the logging engine of their choice, even one not involving Microsoft's abstractions at all?

@geoperez @mariodivece any thought?

Anyone feel free to add your comments and/or vote for this enhancement to find its way into version 5.0 of EmbedIO, as version 4 (already overdue) will contain enough new stuff for v3 users to digest already.

[gabriele-ricci-kyklos]

I'm attaching to this one according to my issue regarding logging https://github.com/unosquare/embedio/issues/513.

should both EmbedIO and SWAN use Microsoft.Extensions.Logging.Abstractions, and SWAN contain an implementation of ILoggerFactory?

In my opinion, you should definitely support Microsoft.Extensions.Logging.Abstractions, and make the SWAN logger one possible implementation, allowing the developer using your library to decide which framework to use. For instance, I'm using NLog behind the scenes, but I'm forced to implement the logging myself through the Swan.Logging.ILogger interface. Moreover you could add some extension methods to quickly integrate some of the most common loggers with a specific nuget package. An example is the MassTransit library, which uses Microsoft.Extensions.Logging.Abstractions for its logging abstractions, then attaches Serilog logger by default. Some developers created however some side nuget packages, such as MassTransit.NLog, providing extension methods like config.UseNLog() to be used like your library's WebServer fluent interface. You'd be able to do like

var _webServer =
    new WebServer(o => o
        .WithUrlPrefix($"http://localhost:12345/")
        .WithMode(HttpListenerMode.Microsoft)
        .UseNLog() -- NLog logger
)

Your SWAN logger could very well be the default logging implementation for the logging abstraction of the library.

do other logging abstractions exist of which we should be aware, maybe deserving more attention than Microsoft.Extensions.Logging.Abstractions?

The most famous logging abstraction is Common.Logging, that's because it was written years before Microsoft's Microsoft.Extensions.Logging.Abstractions. I believe though that most common logging frameworks support both, and I would definitely go for the Microsoft abstraction, considering .NET Core developers will prefer that one, and .NET Framework being replaced by .NET Core gradually.

Apart from the logging framework, it would be nice to have well-defined system for logging request / response in a context of a Web API, but that's another story.

Hope it helps.

[bdurrer]

We use MetroLog with a Swan2Metro bridge, which was easy enough to implement. While MetroLog is nice for cross-platform, it seems to be pretty much inactive - I'm certainly not recommending it for anything.

[rdeago]

@gabriele-ricci-kyklos thanks for your insight and the additional info. I agree 100% that Microsoft's abstractions are currently a better option than Common.Logging.

As for request / response logging, it's a feature to evaluate thoroughly: while certainly useful, it would bring along a performance burden that maybe not everyone is willing to accept. I'd suggest to open a feature request on the subject, so as to invite a specific discussion. I took the liberty to modify the title of your previous issue #513, so you can title the feature request appropriately.

Thanks @bdurrer for pointing out that a logging bridge for SWAN is a viable solution. As a matter of fact, it boils down to two easy tasks:

• create a "bridge" class, implementing Swan.Logging.ILogger, that routes all calls to your preferred logging library;
• upon application startup, call Logger.NoLogging() to get rid of the automatically-added loggers, then Logger.RegisterLogger<YourBridgeClass>().