You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Henrik Vendelbo <hv...@bluprints.com> on 2003/09/28 19:12:38 UTC
Logger.getConfigurationFileName()
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
Re: Logger.getConfigurationFileName()
Posted by "slg.ahlen.quvintheumn" <sl...@telia.com>.
----- Original Message -----
From: "Tim Funk" <fu...@joedog.org>
To: "Tomcat Users List" <to...@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" <fu...@joedog.org>
> > To: "Tomcat Users List" <to...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Logger.getConfigurationFileName()
Posted by "slg.ahlen.quvintheumn" <sl...@telia.com>.
----- Original Message -----
From: "Tim Funk" <fu...@joedog.org>
To: "Tomcat Users List" <to...@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" <fu...@joedog.org>
> > To: "Tomcat Users List" <to...@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
>
Re: Logger.getConfigurationFileName()
Posted by Tim Funk <fu...@joedog.org>.
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" <fu...@joedog.org>
> To: "Tomcat Users List" <to...@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
>>>
Re: Logger.getConfigurationFileName()
Posted by Tim Funk <fu...@joedog.org>.
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" <fu...@joedog.org>
> To: "Tomcat Users List" <to...@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
Re: Logger.getConfigurationFileName()
Posted by Henrik Vendelbo <hv...@bluprints.com>.
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
javax.servlet.ServletException: Error instantiating servlet class
net.dspc.server.AxisServletPlus
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:91
2)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:823)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:
3421)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3609)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
at org.apache.catalina.core.StandardService.start(StandardService.java:497)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:2190)
at
org.apache.catalina.startup.CatalinaService.start(CatalinaService.java:273)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.catalina.startup.BootstrapService.start(BootstrapService.java:245
)
at
org.apache.catalina.startup.BootstrapService.main(BootstrapService.java:307)
----- Root Cause -----
java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces
sorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstruc
torAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:308)
at java.lang.Class.newInstance(Class.java:261)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:90
3)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:823)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:
3421)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3609)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
at org.apache.catalina.core.StandardService.start(StandardService.java:497)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:2190)
at
org.apache.catalina.startup.CatalinaService.start(CatalinaService.java:273)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.catalina.startup.BootstrapService.start(BootstrapService.java:245
)
at
org.apache.catalina.startup.BootstrapService.main(BootstrapService.java:307)
Caused by: org.apache.commons.logging.LogConfigurationException:
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.newInstance(LogFactoryImpl.ja
va:532)
at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.ja
va:272)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:414)
at org.apache.axis.components.logger.LogFactory.getLog(LogFactory.java:76)
at
org.apache.axis.transport.http.AxisServletBase.<clinit>(AxisServletBase.java
:94)
... 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" <fu...@joedog.org>
To: "Tomcat Users List" <to...@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
>
>
>
>
Re: Logger.getConfigurationFileName()
Posted by Henrik Vendelbo <hv...@bluprints.com>.
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
javax.servlet.ServletException: Error instantiating servlet class
net.dspc.server.AxisServletPlus
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:91
2)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:823)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:
3421)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3609)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
at org.apache.catalina.core.StandardService.start(StandardService.java:497)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:2190)
at
org.apache.catalina.startup.CatalinaService.start(CatalinaService.java:273)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.catalina.startup.BootstrapService.start(BootstrapService.java:245
)
at
org.apache.catalina.startup.BootstrapService.main(BootstrapService.java:307)
----- Root Cause -----
java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces
sorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstruc
torAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:308)
at java.lang.Class.newInstance(Class.java:261)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:90
3)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:823)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:
3421)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3609)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
at org.apache.catalina.core.StandardService.start(StandardService.java:497)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:2190)
at
org.apache.catalina.startup.CatalinaService.start(CatalinaService.java:273)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.catalina.startup.BootstrapService.start(BootstrapService.java:245
)
at
org.apache.catalina.startup.BootstrapService.main(BootstrapService.java:307)
Caused by: org.apache.commons.logging.LogConfigurationException:
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.newInstance(LogFactoryImpl.ja
va:532)
at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.ja
va:272)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:414)
at org.apache.axis.components.logger.LogFactory.getLog(LogFactory.java:76)
at
org.apache.axis.transport.http.AxisServletBase.<clinit>(AxisServletBase.java
:94)
... 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" <fu...@joedog.org>
To: "Tomcat Users List" <to...@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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Logger.getConfigurationFileName()
Posted by Tim Funk <fu...@joedog.org>.
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
Re: Logger.getConfigurationFileName()
Posted by Tim Funk <fu...@joedog.org>.
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
>