logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4J2-1547) The Core AbstractConfiguration should track its LoggerContext and add Configuration.getLoggerContext()
Date Thu, 25 Aug 2016 23:58:21 GMT

    [ 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: ralph.goers@dslextreme.com):
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message