tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Funk <funk...@joedog.org>
Subject Re: Logger.getConfigurationFileName()
Date Sun, 28 Sep 2003 23:49:22 GMT
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" <funkman@joedog.org>
> To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
> 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
>>>



Mime
View raw message