-
Notifications
You must be signed in to change notification settings - Fork 130
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
feature request: logger taking context from mixin #208
Comments
@analytically WDYT? |
PR? |
@analytically i'll try and do it in the next few days, thanks! |
grunzwei
added a commit
to grunzwei/scala-logging
that referenced
this issue
Mar 24, 2020
… you don't want to pass it each time via implicit for every call, just set it once when you instantiate the logger. see lightbend-labs#208
grunzwei
added a commit
to grunzwei/scala-logging
that referenced
this issue
Mar 24, 2020
… you don't want to pass it each time via implicit for every call, just set it once when you instantiate the logger. see lightbend-labs#208
WIP, have some pain points as mentioned in description, also i just realized one of the usecases i wanted to support won't work because the logger call site will be incorrect. would appreciate advice if you have any. @analytically FYI |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
TL;DR I need another type of logger, other than regular or
LoggerTakingImplicit
. I need aLoggerInMixinContext
or something like that.scala-logging has Logger and
Logger.takingImplicit[Context](canLogContext)
,Logger has no concept of context,
LoggerTakingImplicit
assumes context is passed on each method implicitly.I have chosen a different strategy to handle context: create an instance per request, bound to the context, like so:
I need a logger that can take the context from the instance it's mixed in with, rather than the context passed implicitly on each method.
something like this maybe
I tried doing something like that myself but all of your classes are private final (especially the macro expansions, so i can't implement our own logger like this).
umm, why is that btw?
The reason why i can't just use the logger taking implicit even in my use case (the callscope is available and can be implicit, so why not just use it?) is because i want to abstract away the context from the core:
Since in core/domain "pure" MyClass there is no implicit Context or concept of context at all, I would not be able to use the LoggerTakingImplicit which requires context on invocation of any log method.
If you approve of this idea but don't think it has high priority or wish to implement it yourselves i am open to contributing to you it via PR if you are willing to merge it when it's done.
Alternatively, if you would be willing to make your macros / traits / classes public and not private final, so consumers can reuse them to compose additional loggers, that would also be great...
many thanks!
The text was updated successfully, but these errors were encountered: