No your not. Except calling a pre class with a set of properties will
be more flexible.
On 9/29/12, Ralph Goers wrote:
> 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.getRe
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 configu
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 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 ye
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.
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
us
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 d
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 wrote:
> The problem I have is that it isn't determinis
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 n
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 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
t
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
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.i
11 matches
Mail list logo