On Thu, Mar 21, 2024 at 9:58 PM Ralph Goers <ralph.go...@dslextreme.com>
wrote:
>
> > On Mar 21, 2024, at 2:48 PM, Raman Gupta <rocketra...@gmail.com> wrote:
> >
> > On Thu, Mar 21, 2024 at 5:30 AM Piotr P. Karwasz <
> piotr.karw...@gmail.com>
> > wrote:
> >
> >> Hi Ralph,
> >>
> >> On Thu, 21 Mar 2024 at 07:03, Ralph Goers <ralph.go...@dslextreme.com>
> >> wrote:
> >>>> 1. Raman and Mikko would like to bind context data to an object
> >>>> implementing the `Logger` interface or more generally to a service
> >>>> object (e.g. resource manager, DAO and variants),
> >>>
> >>> Yes, I’ve seen that. Personally, I am not much of a fan of this use
> case
> >> as it is pretty easy to add the data you want to a single class. That
> said,
> >> we already offer a solution. Allowing a MessageFactory to be provided
> on a
> >> Logger was done for exactly this reason.
> >>>
> >>> For example, a User could configure a custom MessageFactory that
> >> provides an extension of MapMessage that causes the message to include
> data
> >> from the class or resource. Going to the extreme of trying to shoehorn
> in
> >> Context data as well simply isn’t necessary.
> >>
> >> Great point! This effectively solves Raman's and Mikko's problem. We
> >> just need to introduce a new sub-interface of `Message` and require
> >> all implementations to support it.
> >>
> >>
> > I'm not sure it does. I differentiate between context and message. When I
> > want the data from the resource in the context, it's because the data is
> > contextual, not part of the message.
> >
> > This approach seems to be not much better than making sure all log
> messages
> > in a class have a consistent string format so it can be grepped.
>
> No, it is nothing like that. LogEvents effectively support 2 kinds of
> Maps; those associated with the ThreadContext (or injected into the
> LogEvents contextMap, or key/value pairs associated with MapMessages. In
> the PatternLayout these are distinguished by %X and %K. If you know the
> keys you want you can use a pattern like:
>
> %d %p %C{1.} [%t] {requestId=%X{requestId}
> customerNumber=%X{customerNumber} userName=%K{userName} %{userType} - %m%n
>
> Thus making the ThreadContext key/values and Message key/values virtually
> indistinguishable.
When one controls the layout with something like PatternLayout, yes.
However in structured logging use cases (e.g. to Google Cloud Logging) the
context and message maps are shown under separate "context" and "message"
keys. As they should be because they are different things.
We have context and we have a message -- I don't think it should be
considered best practice to conflate these.
> The only issue at the moment is the result of %m on a MapMessage isn’t
> really what you would like. I am looking into addressing that as I have run
> across this before in things I have tried to do.
>
> Ralph
