First, developers of libraries that package the log4j library within their own
jar should be admonished. It can only be harmful to users. Developers of
libraries that package a Log4j config file in their own library should be
alerted to the error of their ways (something less than "admonishment").
Log4j cannot very well resolve Java classloading issues. Something like OSGi
might be able to, but not the Log4j project. In any case, knowing that there
are existing libraries that behave badly, the question becomes, "how do we
work around it?" Well, below are some suggestions....
Where did you put your own properties file? If you put it earlier in the
classapth than the libraries, then you won't have this problem. For instance,
for a webapp, put it in WEB-INF/classes and log4j.jar in WEB-INF/lib (this
assumes that you are using child-first classloading, or at least there is no
log4j.jar in a parent classloader when using parent-first classloading).
There is a chance that if a library packages log4j.xml, it will be used in
preference to log4j.properties because XML config files are used in preference
to Properties config files. In that case, you can just use log4j.xml yourself
and put it in WEB-INF/classes.
Ultimately, you could override auto-configuration using (I could be wrong
about the exact system property name, so please verify before assuming it
works)...
-Dlog4j.autoconfigure=false
Now when you run your own manual configuration, it won't have been previously
autoconfigured.
Actually, what I often do if I want to manually configure is add a dummy
log4j.xml to WEB-INF/classes that sets all logging as being turned off. Then
I manually configure a Log4j config file of my choice.
Jake
On Thu, 15 Nov 2007 13:57:00 -0500
"Jim the Standing Bear" <[EMAIL PROTECTED]> wrote:
Hi all,
From an earlier problem, I discovered that my application wasn't using
the log4j.properties I supplied. In fact, I am not even sure if it
was using the log4j from log4j-1.2.13.jar that I supplied.
This is because my app also uses cog-jglobus, which contains its own
version of log4j. By turning on the debug option, I discovered that
the log4j was first looking for XML properties file, which it could
not find, then it somehow knew there would be a log4j.properties file
packaged in cog-jglobus-1.4.jar, and it used that instead. After I
repackaged cog-jglobus by removing the log4j.properties, it started
to use the properties file that came with axis2-0.93.jar.
So it becomes impractical for me to repackage every single frigging
jar that comes with its own log4j.properties. So what is the best way
to specify the app to use the log4j from log4j-1.2.13.jar, as well as
my own log4j.properties?
Currently my code reads a properties file for the application, and one
property specifies where logj4.properties is. I would then use that
property value to supply PropertyConfigurator.configure() in the
constructor of the entry class. It seems that this may not be the
best way to do so since log4j automatically read other properties file
prior to this one.
Thanks.
-- Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
