ppkarwasz commented on PR #2419:
URL: https://github.com/apache/logging-log4j2/pull/2419#issuecomment-2027966002

   > @ppkarwasz You have flagged this as "Changes Requested". It isn't really 
clear what you have requested. If it is to remove ScopedContext that isn't 
going to happen so we will have to work that out. If it is something else 
please let me know.
   
   Yes, in general I am +10 on `ParameterizedMapMessage` and -1 on 
`ScopedContext`. What  I would like to change in this PR mostly falls into two 
categories:
   
   - size down the impact on the public API, now that we know that we can not 
make breaking changes in the API for a very long time,
   - decouple the contract of the new API from its implementation, by using 
**well-documented** interfaces.
   
   In particular:
   
   1. Is there something wrong with adding new methods to 
`CloseableThreadContext` instead of creating a new `ScopedContext`?
   2. You introduce another `ThreadLocal` containing context data: all the 
libraries that read context data for metrics or traces will need to be updated. 
Could we reuse `ThreadContextMap`? `log4j-to-slf4j` will also ignore the scoped 
context.
   3. Multiple `ContextDataProvider`s currently don't work very well: you will 
not be able to use your scoped data in a `${ctx:…}` lookup (see #2331),
   4. Can we replace the static factory methods in `ResourceLogger` with new 
instance methods of `Logger`?
   5. `ResourceLoggerBuilder` could be an interface: in `log4j-to-slf4j` I 
might want to implement it differently.
   6. `ResourceLogger` should not appear in the signature of 
`ResourceLoggerBuilder#build()`: from a user perspective, it is nothing more 
than a `Logger`.
   7. `ParameterizedMapMessage` should have a matching interface:
   
       * we might want to implement a reusable version of that interface,
       * we want to hide from users all the irrelevant `MapMessage` methods: 
`MapMessage` implements `MultiFormatStringBuilderFormattable` and is mutable,
       * the interface should **precisely** describe what is the effect a user 
will get if he uses it. The Javadoc of 
[`Message#getFormat`](https://logging.apache.org/log4j/2.x/javadoc/log4j-api/org/apache/logging/log4j/message/Message.html#getFormat())
 is a counter-example of a precise description. We might as well have written 
"Undefined behavior".


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

Reply via email to