[
https://issues.apache.org/jira/browse/LOG4J2-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15438163#comment-15438163
]
Ralph Goers edited comment on LOG4J2-1547 at 8/25/16 11:57 PM:
---------------------------------------------------------------
Unfortunately, this is one of the downsides of programmatic configuration. I
really don't see any way around this. Passing the LoggerContext through the
Configuration is the right thing to do. The only way out of this would be to
have AbstractConfiguration have a constructor that doesn't take the
LoggerContext as an argument and calls LogManager.getLoggerContext(false),
which is really calling the configured ContextSelector's getContext method with
a value of false. Of the Selectors we provide only the
ClassLoaderContextSelector does anything with it. If the value is true it
expects to find the LoggerContext in a ThreadLocal. If it is false it locates
it in a Map that associates the LoggerContext to the ClassLoader. As you might
imagine, the second lookup very much depends on what class is calling the
selector. If it is called from Log4j then it will get Log4j's ClassLoader and
thus its LoggerContext, not that of the application. OTOH, if we always set the
ContextAnchor to the LoggerContext we want to use and then have the Constructor
use a value of "true" we could get away with not needing to pass the argument
(so long as we reset it back after the call completes). But this seems fragile.
FWIW, I am fine with the commit.
was (Author: [email protected]):
Unfortunately, this is one of the downsides of programmatic configuration. I
really don't see any way around this. Passing the LoggerContext through the
Configuration is the right thing to do. The only way out of this would be to
have AbstractConfiguration have a constructor that doesn't take the
LoggerContext as an argument and calls LogManager.getLoggerContext(false),
which is really calling the configured ContextSelector's getContext method with
a value of false. Of the Selectors we provide only the
ClassLoaderContextSelector does anything with it. If the value is true it
expects to find the LoggerContext in a ThreadLocal. If it is false it locates
it in a Map that associates the LoggerContext to the ClassLoader. As you might
imagine, the second lookup very much depends on what class is calling the
selector. If it is called from Log4j then it will get Log4j's ClassLoader and
thus its LoggerContext, not that of the application. OTOH, if we always set the
ContextAnchor to the LoggerContext we want to use and then have the Constructor
use a value of "true" we could get away with not needing to pass the argument
(so long as we reset it back after the call completes). But this seems fragile.
> The Core AbstractConfiguration should track its LoggerContext and add
> Configuration.getLoggerContext()
> ------------------------------------------------------------------------------------------------------
>
> Key: LOG4J2-1547
> URL: https://issues.apache.org/jira/browse/LOG4J2-1547
> Project: Log4j 2
> Issue Type: New Feature
> Reporter: Gary Gregory
> Assignee: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> The class in Core, {{AbstractConfiguration}}, should track its
> {{LoggerContext}} and provide it with a new API
> {{Configuration.getLoggerContext()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
