package logging
- Alphabetic
- By Inheritance
- logging
- AnyRef
- Any
- Hide All
- Show All
- Public
- Protected
Type Members
- final class ContextualizedLogger extends AnyRef
- final class LoggingContext extends AnyRef
- type LoggingContextOf[+P] = T[P]
Value Members
- object ContextualizedLogger
- object JsonStringSerializer
- object LoggingContext
- object LoggingContextOf
LoggingContext with a phantom type parameter representing what kind of details are in it.
LoggingContext with a phantom type parameter representing what kind of details are in it. If a function that accepts a LoggingContext is supposed to trust that the caller has already embedded all the relevant data that would be passed as arguments into the context, then you could say a function that accepts a LoggingContextOf will "trust, but verify" instead.
You can pick a tag to represent each kind of data you want to appear in a context. The use of
+
means the tag language inLoggingContextOf[Tag]
reflects the subtyping relation built into Scala, andAny
andwith
form the zero and append of a commutative monoid of tags.A few, but not all, type-level implications of this:
LoggingContextOf[Foo with Bar]
is-aLoggingContextOf[Foo]
LoggingContextOf[Foo with Bar]
is-aLoggingContextOf[Bar]
LoggingContextOf[Elephant]
is-aLoggingContextOf[Animal]
LoggingContext
is-aLoggingContextOf[Any]
A context with a more specific scope will always be preferred in implicit resolution. So if you call a function demanding a
LoggingContextOf[Foo]
and you have two implicits in scope, aLoggingContextOf[Foo]
and aLoggingContextOf[Foo with Bar]
then the latter will be chosen, in accordance with SLS §7.2, §6.26.3. This fits well the "more context = better than" overall philosophy of the contextualized-logging library. - object LoggingValueStringSerializer