> 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.
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
