rocketraman commented on PR #2419:
URL: https://github.com/apache/logging-log4j2/pull/2419#issuecomment-2025107929
@rgoers
> If you have other requirements for how the data should be formatted I am
sure JsonTemplateLayout could be enhanced to support it, if it can't do it
already.
I understand that if one has end-to-end control over layout, we can use the
approach you've created here. However, we have a meaningful and clear
separation between logging and layout. This means it is absolutely normal for
developers to configure application logging, while some completely different of
people (enterprise dev tooling group or perhaps upstream library such as Spring
Boot) determines layout, and in many cases developers have no ability to affect
layout at all -- all applications across the enterprise use the same layout in
order to enforce logging consistency. My references to Google Cloud Logging are
for just such a case at an enterprise client of mine in which the logs in their
Google Cloud have a `context` key for all contextual data, and I have
absolutely no control over that. With your solution, my resource context will
sometimes be in `context` and sometimes be in `message`. Furthermore, my
`message` field won't even be consistent -- sometimes it will be a `Str
ing`, and sometimes it will be a `Map` of fields (unless I control the
layout). This is just completely surprising behavior for a user.
If we want to blur the separation between context and message, then lets go
all the way. Put everything into message, and then come up with an appropriate
solution in order to distinguish different types of fields for layout. Make it
a breaking change for Log4j3.
> The problem is that Loggers are singletons and the code where the LogEvent
is constructed and the ContextMap is populated is pretty far down the stack.
I'm not as familiar with Log4j internals as you and @ppkarwasz . However,
from the perspective of a naiive user, I'm not sure what is so difficult? As a
user I could wrap my logger in my own class that, for every method, did (in
pseudo-code):
```
class ContextLogger {
private final Map<String, String> context;
private final Logger delegate;
void log(...) {
setContext(context)
try {
delegate.log(...)
} finally {
resetContext()
}
}
}
```
and (I believe) problem solved. However, this should be unnecessary for a
user to do.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
