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. > To be sure we don't cherry-pick each element of a log event with a > different interface (like we did with `TimeStampMessage`), let's use a > single interface to supply all the additional data the user might want > to have. Let's throw in it Ceki's `KeyValuePair`s[1] > > Piotr > > [1] https://www.slf4j.org/api/org/slf4j/event/LoggingEvent.html >
