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