Me neither but it can be very neat occasionally. Agreed and it also applies fine things like Tracing. But logger? If you change logger implementation you have to have a wrapper or you have to change the type conversions everywhere. Maybe refactoring tools can help I guess but I miss a common interface for logging. There was some promising work alas no consensus afaik.
fre 25 aug. 2017 kl 08:47 skrev Peter Mogensen <a...@one.com>: > > > On 2017-08-25 08:31, Henrik Johansson wrote: > > How do you code for storing a logger in context.Value? The same usual > > issues with lacking a shared logger interface happens or did I miss > > something neat? > > > > I try not to do logging from libraries. So logging (and the logger > interface) is specific to my application. > > Internally I would pass loggers as arguments, but using context.Context > becomes relevant when building a middleware stack. So the application > installs both the middleware creating the logger and the handler using > it. (and they then both know the type). > There can be other application specific request-scoped stuff you want to > pass along down the middleware stack - such as > Authentication-ID/Authorization-ID. So there's ususally an application > specific requestcontext and not just a logger. > > /Peter > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
