----- Original Message ----- From: "Tim Funk" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Monday, September 29, 2003 1:49 AM Subject: Re: Logger.getConfigurationFileName()
> 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
