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
