Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we repurpose this library to make a bridge adapter for Microsoft.Extensions.Logging ? #21

Open
Aaronontheweb opened this issue Oct 29, 2020 · 5 comments

Comments

@Aaronontheweb
Copy link
Contributor

The Common.Logging library has been deprecated, somewhat, as its role in the .NET ecosystem was effectively usurped my the standard libraries Microsoft introduced as part of the .NET Core rollout in early 2017: Microsoft.Extensions.Logging

Should we repurpose this library to target those going forward? Or should we create an entirely new library for the purpose of targeting those? We can programmatically inject a configured ILogger from Microsoft.Extensions.Logging via the new Setup type introduced in Akka.NET v1.4.

Or, we can add a new library altogether as part of the Akka.NET core library (it'd be a separate package, but part of the main repository) - what should we do?

@ericsampson
Copy link

Microsoft.Extensions.Logging.Abstractions right?

@Aaronontheweb
Copy link
Contributor Author

@ericsampson yep - whatever the best base library is to target the logging abstractions inside ASP.NET Core and so on

@Aaronontheweb
Copy link
Contributor Author

My vision here: make it trivially easy for someone to take the logger they wired up for ASP.NET Core and inject it into an Akka.NET ActorSystem at startup.

@Danthar
Copy link
Contributor

Danthar commented Oct 29, 2020

I would say re-purpose this library to be a bridge between Microsoft.Extensions.Logging and the Akka.Net logging infra.
And then, in time, deprecate the logging specific plugins.
The only thing we probably would need to pay some special attention to, i think, is how we are going to expose the logging format. Since some logging extensions have some fairly specific definitions, to utilize their own logging specific features to the fullest.
I'd expect we would lose some functionality there due to the abstraction that Microsoft.Extensions.Logging enforces. But haven't used it myself yet, so it might be a non-issue.

@Aaronontheweb
Copy link
Contributor Author

@Danthar alright, I'll give this a stab inside the main repository and see if I can come up with a minimally invasive prototype.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants