tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "slg.ahlen.quvintheumn" <slg.ahlen.quvinthe...@telia.com>
Subject Re: Logger.getConfigurationFileName()
Date Mon, 29 Sep 2003 07:34:22 GMT

----- Original Message ----- 
From: "Tim Funk" <funkman@joedog.org>
To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
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" <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
> >>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>



Mime
View raw message