[
https://issues.apache.org/jira/browse/LOG4J2-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker resolved LOG4J2-614.
--------------------------------
Resolution: Implemented
Assignee: Matt Sicker
Implemented in r1590326.
> Log4j API should allow specifying a LoggerContextFactory at runtime.
> --------------------------------------------------------------------
>
> Key: LOG4J2-614
> URL: https://issues.apache.org/jira/browse/LOG4J2-614
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
> Affects Versions: 2.0-rc2
> Reporter: Matt Sicker
> Assignee: Matt Sicker
> Priority: Blocker
> Labels: api, osgi
>
> h3. The Problem
> LogManager uses a private static final LoggerContextFactory which is
> determined in the static initialization block. If the provider isn't
> available yet (e.g., in an OSGi environment), it will fall back to
> SimpleContextFactory and won't allow a different LoggerContextFactory to take
> its place when available.
> h3. Proposed Solution
> The initialization code in LogManager will need to be refactored. The
> presence of a LoggerContextFactory implementation may not be available at the
> same time log4j-api is started. Thus, LogManager can shortcut to using
> SimpleContextFactory by default and then allow that to be overridden. This is
> currently a private static final field; I believe that it would be a better
> idea to use a sort of atomic reference pattern here (or volatile?). I'm not
> sure which way would be the fastest, but it shouldn't be final (I don't want
> to use reflection to force a different LoggerContextFactory like I'm doing
> for the JUL bridge I'm working on).
> In this scenario, it might be useful for the Loggers and LoggerContexts
> returned by SimpleContextFactory to be proxy classes so that they use
> whatever the active logger provider is. This way, if a client gets a Logger
> before log4j-core is activated, it can still use the proper logging objects.
> I don't know how much this affects performance, but java.util.logging uses a
> similar strategy for its loggers before java.util.logging.LogManager is
> initialized.
> Anyway, the main thing to do this here for is to allow all the other log4j
> JARs to not have to be fragments. This will allow for more robust OSGi
> integration and support in log4j-core later on (e.g., registering plugins
> through the OSGi service registry). It might also aid in some neat Spring
> integration, too (i.e., the ability to configure your loggers and appenders
> and such through Spring), but that's a separate idea.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
