With just using a rank the test impl would be lower than the core impl and so
the core impl would be chosen and yes. it would work.
The user already has a way to specify the factory they want with a system
property, but I'd prefer something better than that. It might be nice to allow
a log4j2.properties file that can specify the LoggerContextFactory and
ContextSelector and possibly other things. I'm not really sure about this -
just looking for better ideas.
Ralph
On Sep 28, 2012, at 3:06 PM, Gary Gregory wrote:
> OK, so back to:
>
> "I think a better way to do this is to add one more piece of information to
> the meta-data - a rank/weight as is being done with the configuration
> factory. Then we will pick the one with the highest rank."
>
> So I really want my impl, I scan the system and edit some config file and use
> a higher rank? Seems for advanced users but workable.
>
> In the case I have today, the test impl would have a lower rank than the
> stock impl? Then it would work within an IDE. Check?
>
> Gary
>
> On Fri, Sep 28, 2012 at 5:55 PM, Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
> While it is consistent I wouldn't call it deterministic. For example, JBoss 5
> has an SLF4J implementation in common/lib. Your application may have one in
> WEB-INF/lib. One of them will always win but how is it deterministic which
> one it will be? What if it isn't the one you want? What can be done to
> override it?
>
> Ralph
>
>
> On Sep 28, 2012, at 1:01 PM, Gary Gregory wrote:
>
>> Agree but doesn't the current code use the classpath order? If not, could
>> it? That would be deterministic, just like I can place a jar at the front of
>> the CP to override one or more classes.
>>
>> Gary
>>
>> On Fri, Sep 28, 2012 at 3:51 PM, Ralph Goers <ralph.go...@dslextreme.com>
>> wrote:
>> The problem I have is that it isn't deterministic and I very much dislike
>> that. SLF4J is that way today and it is annoying that you can't guarantee
>> the winner.
>>
>> Ralph
>>
>>
>>
>> On Sep 28, 2012, at 11:21 AM, Gary Gregory wrote:
>>
>>> What about just picking the first one like in the example below (note the
>>> new error message)
>>>
>>> Gary
>>>
>>> On Sep 28, 2012, at 14:06, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>>>
>>>> That is interesting. So Eclipse is seeing both the API's test factory and
>>>> the real implementation. I guess that makes sense. I would probably have
>>>> the same problem in IntelliJ except that I never run tests for anything in
>>>> my IDE but always run Maven from the command line - even to debug.
>>>>
>>>> At one point I considered allowing multiple implementations, but passing
>>>> events to two logging implementations seems like a performance nightmare.
>>>> Also, the Log4j 2 API isn't really intended as a competitor or replacement
>>>> for SLF4J.
>>>>
>>>> I think a better way to do this is to add one more piece of information to
>>>> the meta-data - a rank/weight as is being done with the configuration
>>>> factory. Then we will pick the one with the highest rank.
>>>>
>>>> Ralph
>>>>
>>>> On Sep 28, 2012, at 10:51 AM, Gary Gregory wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I am using Eclipse as my IDE and when I run
>>>>> org.apache.logging.log4j.core.BasicLoggingTest I get an NPE because
>>>>> org.apache.logging.log4j.LogManager.factory is null. It is null because
>>>>> when the static initializer runs it picks up 2 factories instead of one:
>>>>>
>>>>> [org.apache.logging.log4j.core.impl.Log4jContextFactory@39c8c1,
>>>>> org.apache.logging.log4j.SimpleLoggerContextFactory@1ab2b55].
>>>>>
>>>>> Can we be more lenient?
>>>>>
>>>>> Instead of:
>>>>>
>>>>> if (factories.size() != 1) {
>>>>> logger.fatal("Unable to locate a logging implementation");
>>>>> } else {
>>>>> factory = factories.get(0);
>>>>> }
>>>>>
>>>>> How about:
>>>>>
>>>>> if (factories.size() != 1) {
>>>>> logger.error("Expected a single logging implementation,
>>>>> not {}, picking the first: {}", factories.size(), factories.get(0));
>>>>> }
>>>>> factory = factories.get(0);
>>>>>
>>>>> ?
>>>>>
>>>>> --
>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>>>>> Spring Batch in Action: http://bit.ly/bqpbCK
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
