I'm not sure I understand what you are saying, but if I do I am not worried
about how the properties could be located. It would be easy for LogManager to
do a System.getResource("log4j2.properties") and then require the application
to have that somewhere on the classpath if they want to configure this. I'm
just not certain if that is the best way to do it or not. I'm not sure I'd like
to require a system property to be set to enable using the properties. If we do
that they they might as well have to specify the items themselves as system
properties.
Am I missing what you are suggesting?
Ralph
On Sep 28, 2012, at 10:30 PM, Tushar Kapila wrote:
> Java has a pre main. Like wise have another file xml or properties for
> log4j but default null & disabled. Have to set system property to
> enable it.
>
> On 9/29/12, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>> 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
>>
>>
>
> --
> Sent from my mobile device
>
> Regards
> Tushar Kapila
>
> ---------------------------------------------------------------------
> 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
