You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Matt Sicker (JIRA)" <ji...@apache.org> on 2014/04/24 23:17:14 UTC
[jira] [Created] (LOG4J2-614) Log4j API should allow specifying a
LoggerContextFactory at runtime.
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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [jira] [Created] (LOG4J2-614) Log4j API should allow specifying a
LoggerContextFactory at runtime.
Posted by Matt Sicker <bo...@gmail.com>.
Whoops, my bad. Updated the report to include a quick summary of the
problem.
On 24 April 2014 18:45, Gary Gregory <ga...@gmail.com> wrote:
> Yes, that's make it easier for the rest of us to understand what is going
> on ;)
>
> Gary
>
>
> On Thu, Apr 24, 2014 at 7:40 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> Matt,
>>
>> Unless you are creating an issue to immediately fix a bug, can you please
>> have the description state what the problem or issue is? You can then
>> either add a subsequent comment or start another paragraph in the
>> description with a heading of “Proposed Solution”. I like to be able to
>> understand what the issue is that needs to be solved without having to
>> infer it by reading the description to the possible solution.
>>
>> Ralph
>>
>> On Apr 24, 2014, at 2:17 PM, Matt Sicker (JIRA) <ji...@apache.org> wrote:
>>
>> > 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-unsubscribe@logging.apache.org
>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: [jira] [Created] (LOG4J2-614) Log4j API should allow specifying a
LoggerContextFactory at runtime.
Posted by Gary Gregory <ga...@gmail.com>.
Yes, that's make it easier for the rest of us to understand what is going
on ;)
Gary
On Thu, Apr 24, 2014 at 7:40 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> Matt,
>
> Unless you are creating an issue to immediately fix a bug, can you please
> have the description state what the problem or issue is? You can then
> either add a subsequent comment or start another paragraph in the
> description with a heading of “Proposed Solution”. I like to be able to
> understand what the issue is that needs to be solved without having to
> infer it by reading the description to the possible solution.
>
> Ralph
>
> On Apr 24, 2014, at 2:17 PM, Matt Sicker (JIRA) <ji...@apache.org> wrote:
>
> > 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-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [jira] [Created] (LOG4J2-614) Log4j API should allow specifying a LoggerContextFactory at runtime.
Posted by Ralph Goers <ra...@dslextreme.com>.
Matt,
Unless you are creating an issue to immediately fix a bug, can you please have the description state what the problem or issue is? You can then either add a subsequent comment or start another paragraph in the description with a heading of “Proposed Solution”. I like to be able to understand what the issue is that needs to be solved without having to infer it by reading the description to the possible solution.
Ralph
On Apr 24, 2014, at 2:17 PM, Matt Sicker (JIRA) <ji...@apache.org> wrote:
> 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-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org