Whoops, my bad. Updated the report to include a quick summary of the problem.
On 24 April 2014 18:45, Gary Gregory <garydgreg...@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 > <ralph.go...@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) <j...@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-unsubscr...@logging.apache.org >> > For additional commands, e-mail: log4j-dev-h...@logging.apache.org >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >> >> > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@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 <boa...@gmail.com>
