[
https://issues.apache.org/jira/browse/LOG4J2-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221880#comment-15221880
]
Greg Thomas commented on LOG4J2-1348:
-------------------------------------
I've got a rough implementation of this already; a CloseableThreadContext keeps
track of what's been added to the ThreadContext, and removes it when closed.
{code}
// Push a message on to the ThreadContext stack
try (final CloseableThreadContext ctc = new
CloseableThreadContext(UUID.randomUUID().toString()) {
logger.debug("Message 1");
...
}
{code}
and
{code}
// Pop two key/value pairs on to the ThreadContext map
try (final CloseableThreadContext ctc = new CloseableThreadContext("id",
UUID.randomUUID().toString(), "ipAddress", request.getRemoteAddr()) {
logger.debug("Message 1");
...
}
{code}
But that can lead to a nasty cast when you want to push a formatted message if
all the parameters are Strings;
{code}
// Push a formatted message on to the ThreadContext stack
final String username = user.getUsername();
try (final CloseableThreadContext ctc = new CloseableThreadContext("user={}",
(Object)username) {
logger.debug("Message 1");
....
}
{code}
This could be avoided by having two different classes; one with a
{{CloseableThreadContextStack(String, Object...)}} constructor and one with a
{{CloseableThreadContextMap(String, String, String...)}} constructor, but I'm
not sure which I prefer.
If a single class is sufficient, then should it be rolled in to the
ThreadContext itself, currently entirely {{static}}, or are there benefits to
have a second class for the AutoCloseable ?
> AutoCloseable ThreadContext access
> ----------------------------------
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Affects Versions: 2.5
> Reporter: Greg Thomas
> Priority: Minor
>
> The log4j2 API provides a ThreadContext -
> https://logging.apache.org/log4j/2.x/manual/thread-context.html - that
> allows items to be added to a stack or a map for logging, and then
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so
> that items are removed automatically and no longer left around littering the
> stack/map.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
