Matt Sicker created LOG4J2-614:
----------------------------------

             Summary: 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
            Priority: Blocker


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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Reply via email to