[
https://issues.apache.org/jira/browse/LOG4J2-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-614:
-------------------------------
Description:
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.
was:
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.
> 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
> 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]
