Open MopsiMauser opened 4 years ago
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:
Microsoft.Extensions.Logging.Abstractions
, and SWAN contain an implementation of ILoggerFactory
?Swan.Logging
library, so it doesn't weigh on installations that do not use it?Microsoft.Extensions.Logging.Abstractions
?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.
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.
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.
@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:
Swan.Logging.ILogger
, that routes all calls to your preferred logging library;Logger.NoLogging()
to get rid of the automatically-added loggers, then Logger.RegisterLogger<YourBridgeClass>()
.
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.