On Thu, Mar 21, 2024 at 6:19 PM Piotr P. Karwasz <piotr.karw...@gmail.com>
wrote:
> Hi Raman,
>
> On Thu, 21 Mar 2024 at 22:51, Raman Gupta <rocketra...@gmail.com> wrote:
> > > > 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.
>
> I was thinking about a code like this:
>
> private static final Logger mainLogger = LogManager.getLogger();
>
> private final Logger logger;
>
> public ResourceManager() {
> Map<String, String> contextData = Map.of(...);
> logger = mainLogger.withMessageFactory(new
> ContextualMessageFactory(contextData));
> }
>
> The new `Logger#withMessageFactory` method will give you a logger with
> the same name as `mainLogger`, but with a different message factory.
> The message factory will create LogEvents initialized with the given
> context, which will be further complemented by the context data
> injected by ContextDataInjector. Is this the effect you are looking
> for?
>
Yes, your description sounds like what I'm looking for, but I am confused
with the name `withMessageFactory`. As I understand it, the
`MessageFactory` interface allows creating Messages, not LogEvents with
context.
Thanks,
Raman
> Piotr
>
> PS: In the `main` branch I plan to replace the default
> ReusableMessageFactory with ReusableLogEventFactory:
>
> * this change should have a minimal impact on memory (events are not
> much larger than messages),
> * it can skip a data transfer between ReusableMessage and MutableLogEvent,
> * it allows the message factory to collect data that is usually
> reserved for events.
>
