Re: Logger.getConfigurationFileName()

[Tim Funk]

There was a similar post today that the Root cause message you are seeing is 
usually caused by multiple (conflicting?) versions of the same class. Which 
is probably log4j, and/or commons-logging.

-Tim

Henrik Vendelbo wrote:

It seem so simple doesnt it? Whenever I read the Log4j docs, the scheme
always seemed simle
and effective. Well, I have not spent two days trying to figure out why my
Axis webservice fails. And
logging is currently adding a lot of pain rather than help to the process.
The thing is that once things start going wrong, you start looking at the
foundation and what it actually does.
If I could just verify that log4j is actually getting configured the way I
want it to, I could have saved 5 hours tinkering.
So basicly my approach is that knowing the principles is very nice, but
facts are preferable.
I ended up putting log4j.properties in the CATALINA_HOME/classes dir. Now I
can't even load the Axis servlet.
Hopefully this isn't causing it, but I would give a lot for a peek into what
actually happens during load.
2003-09-28 20:56:57 StandardWrapper[/dspc:DspcAxisServlet]: Marking servlet
DspcAxisServlet as unavailable
2003-09-28 20:56:57 StandardContext[/dspc]: Servlet /dspc threw load()
exception
 > ----- Root Cause -----
java.lang.ExceptionInInitializerError
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces
 ... 23 more
Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Class
org.apache.commons.logging.impl.Log4JLogger does not implement Log
 at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryI
mpl.java:416)
 at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.ja
va:525)
 ... 27 more
Caused by: org.apache.commons.logging.LogConfigurationException: Class
org.apache.commons.logging.impl.Log4JLogger does not implement Log
 at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryI
mpl.java:412)
 ... 28 more
----- Original Message ----- 
From: "Tim Funk" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Sunday, September 28, 2003 8:14 PM
Subject: Re: Logger.getConfigurationFileName()



If using log4j, log4j automagically looks for log4j.properties in the
classloader with no package prefix. So if log4j is in $TOMCAT_HOME/lib,
you

can configure it via log4j.properties in $TOMCAT_HOME/classes.

-Tim

Henrik Vendelbo wrote:

With all the flexibility in cofiguring the logging facility, I wonder
if

there is some way to discover how current properties were loaded.

I imagine that getting the absolute path of for instance the
log4j.properties file would be tricky; How about the name of the
ClassLoader
and the relative path ?
Henrik



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]