You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Thorsten Scherler <th...@juntadeandalucia.es> on 2007/10/18 11:56:32 UTC
[JCL] LogConfigurationException headache
Hi all,
I am having major headaches lately with some servlets one based on
forrest 0.8 and another based on Spring 2.0 regarding
logging.
It started when deploying some cocoon application to either tomcat 5 and
6 or Jetty 6.1.x.
You can find an extended background summary (from me and others) here:
https://issues.apache.org/jira/browse/FOR-1049
The problem is that forrest/cocoon logging seems to seriously interfere
with my own one (in the spring servlet). I am using ATM
apache-tomcat-6.0.14 but have seen the exact problems in 5.5.x and Jetty
6.1.x.
I have two servlets one is based on cocoon the other one is a very
simple homegrown one based on Spring.
The logging jars for the cocoon one are
thorsten@awesomeO:~/src/apache/tomcat6/webapps$ tree boja2/WEB-INF/lib/|
grep log
|-- avalon-logkit-2.1.jar
|-- commons-logging-1.1.jar
|-- commons-logging-adapters-1.1.jar
|-- commons-logging-api-1.1.jar
|-- excalibur-logger-2.1.jar
|-- log4j-1.2.13.jar
|-- logkit-1.2.2.jar
The logging for the simple servlet is:
tree searcher/WEB-INF/lib/|grep log
|-- commons-logging-1.1.jar
|-- log4j-1.2.14.jar
Now starting tomcat with only one application it is working fine as well
when I "mv" the other app into tomcat there is no problem but as soon as
I *restart* tomcat. BAAANGG!!
Oct 17, 2007 4:22:07 PM org.apache.catalina.core.StandardContext
loadOnStartup
SEVERE: Servlet /searcher threw load() exception
org.apache.commons.logging.LogConfigurationException: User-specified log
class 'org.apache.commons.logging.impl.LogKitLogger' cannot be found or
is not useable.
at
org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:798)
at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:601)
at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:333)
at
org.apache.commons.logging.LogFactory.getLog(LogFactory.java:664)
at
org.springframework.web.servlet.DispatcherServlet.<clinit>(DispatcherServlet.java:242)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at
java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at java.lang.Class.newInstance0(Class.java:350)
at java.lang.Class.newInstance(Class.java:303)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1104)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:981)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4045)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4351)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:920)
at
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:883)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492)
at
org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at
org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:516)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:566)
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:585)
at
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
I actually do not understand this exception at all since I do not use
LogKitLogger in the "searcher servlet". In my servlet I have something
like:
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
/**
* Simple wrapper class to easier debug/log.
*
*/
public class LoggableSearcher {
protected final Log log =
LogFactory.getLog(this.getClass().getCanonicalName());
public LoggableSearcher() {
super();
}
}
Which I then extend with a Spring Controller.
public class SearchController extends LoggableSearcher implements
Controller {
...
}
I am looking for a solution for a while now but actually have not found
any solution only reports about similar problems.
Can somebody please give me some hints what the problem is and how I can
fix it?
Any input is highly appreciated.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [JCL] LogConfigurationException headache
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Thu, 2007-10-18 at 11:56 +0200, Thorsten Scherler wrote:
> Hi all,
>
> I am having major headaches lately with some servlets one based on
> forrest 0.8 and another based on Spring 2.0 regarding
> logging.
>
> It started when deploying some cocoon application to either tomcat 5 and
> 6 or Jetty 6.1.x.
>
> You can find an extended background summary (from me and others) here:
> https://issues.apache.org/jira/browse/FOR-1049
>
> The problem is that forrest/cocoon logging seems to seriously interfere
> with my own one (in the spring servlet). I am using ATM
> apache-tomcat-6.0.14 but have seen the exact problems in 5.5.x and Jetty
> 6.1.x.
>
> I have two servlets one is based on cocoon the other one is a very
> simple homegrown one based on Spring.
>
> The logging jars for the cocoon one are
> thorsten@awesomeO:~/src/apache/tomcat6/webapps$ tree boja2/WEB-INF/lib/|
> grep log
> |-- avalon-logkit-2.1.jar
> |-- commons-logging-1.1.jar
> |-- commons-logging-adapters-1.1.jar
> |-- commons-logging-api-1.1.jar
> |-- excalibur-logger-2.1.jar
> |-- log4j-1.2.13.jar
> |-- logkit-1.2.2.jar
>
> The logging for the simple servlet is:
> tree searcher/WEB-INF/lib/|grep log
> |-- commons-logging-1.1.jar
> |-- log4j-1.2.14.jar
>
> Now starting tomcat with only one application it is working fine as well
> when I "mv" the other app into tomcat there is no problem but as soon as
> I *restart* tomcat. BAAANGG!!
>
The real problem lies in the web.xml (here forrest).
We use here:
...
<!--
Set commons-logging classes, in particular JCS, to use the logkit
so the log messages
are properly handled by cocoon.
-->
<init-param>
<param-name>force-property</param-name>
<param-value>
org.apache.commons.logging.Log=org.apache.commons.logging.impl.LogKitLogger
</param-value>
</init-param>
<!--
This parameter allows you to startup Cocoon2 immediately after
startup
of your servlet engine.
-->
<load-on-startup>1</load-on-startup>
...
This combination is forcing the usage of the LogKitLogger for ALL
servlets in your servlet container. I tested with Jetty as well and you
will get the same error.
The explanation is that since the cocoon servlet is loaded first we are
setting the org.apache.commons.logging.Log variable for the whole
container.
http://commons.apache.org/logging/troubleshooting.html#Fixes
Meaning no other servlet can override this any more, very bad if you
have different servlets/contexts.
The solution is instead of using an init-param a context-param. This way
every context can handle its on logging:
...
<context-param>
<param-name>force-property</param-name>
<param-value>
org.apache.commons.logging.Log=org.apache.commons.logging.impl.LogKitLogger
</param-value>
</context-param>
...
HTH to have this solution in the archive.
salu2
> Oct 17, 2007 4:22:07 PM org.apache.catalina.core.StandardContext
> loadOnStartup
> SEVERE: Servlet /searcher threw load() exception
> org.apache.commons.logging.LogConfigurationException: User-specified log
> class 'org.apache.commons.logging.impl.LogKitLogger' cannot be found or
> is not useable.
> at
> org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:798)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:601)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:333)
> at
> org.apache.commons.logging.LogFactory.getLog(LogFactory.java:664)
> at
> org.springframework.web.servlet.DispatcherServlet.<clinit>(DispatcherServlet.java:242)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at java.lang.Class.newInstance0(Class.java:350)
> at java.lang.Class.newInstance(Class.java:303)
> at
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1104)
> at
> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:981)
> at
> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4045)
> at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4351)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
> at
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:920)
> at
> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:883)
> at
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492)
> at
> org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
> at
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
> at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
> at
> org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
> at
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
> at
> org.apache.catalina.core.StandardService.start(StandardService.java:516)
> at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:566)
> 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:585)
> at
> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
> at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
>
> I actually do not understand this exception at all since I do not use
> LogKitLogger in the "searcher servlet". In my servlet I have something
> like:
>
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
>
> /**
> * Simple wrapper class to easier debug/log.
> *
> */
> public class LoggableSearcher {
>
> protected final Log log =
> LogFactory.getLog(this.getClass().getCanonicalName());
>
> public LoggableSearcher() {
> super();
> }
>
> }
>
> Which I then extend with a Spring Controller.
> public class SearchController extends LoggableSearcher implements
> Controller {
> ...
> }
>
> I am looking for a solution for a while now but actually have not found
> any solution only reports about similar problems.
>
> Can somebody please give me some hints what the problem is and how I can
> fix it?
>
> Any input is highly appreciated.
>
> salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [JCL] LogConfigurationException headache
Posted by Dennis Lundberg <de...@apache.org>.
Hi
I can see two things directly that may or may not be the cause of your
problems.
1. Always configure your logging implementation.
In your case put a file called "commons-logging.properties" in
searcher/WEB-INF/classes/ with this line only in it:
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
2. Don't use more commons-logging jars than you need.
In your case the 3 jars in the boja2/WEB-INF/lib/ are 2 too many. I'd
remove commons-logging-adapters-1.1.jar and commons-logging-api-1.1.jar
from there. commons-logging-1.1.jar includes all commons-logging
classes. The other two contains subsets of those classes. They are
useful in some servlet containers, if they container itself uses
commons-logging, but a different version than you want in your app.
Thorsten Scherler wrote:
> Hi all,
>
> I am having major headaches lately with some servlets one based on
> forrest 0.8 and another based on Spring 2.0 regarding
> logging.
>
> It started when deploying some cocoon application to either tomcat 5 and
> 6 or Jetty 6.1.x.
>
> You can find an extended background summary (from me and others) here:
> https://issues.apache.org/jira/browse/FOR-1049
>
> The problem is that forrest/cocoon logging seems to seriously interfere
> with my own one (in the spring servlet). I am using ATM
> apache-tomcat-6.0.14 but have seen the exact problems in 5.5.x and Jetty
> 6.1.x.
>
> I have two servlets one is based on cocoon the other one is a very
> simple homegrown one based on Spring.
>
> The logging jars for the cocoon one are
> thorsten@awesomeO:~/src/apache/tomcat6/webapps$ tree boja2/WEB-INF/lib/|
> grep log
> |-- avalon-logkit-2.1.jar
> |-- commons-logging-1.1.jar
> |-- commons-logging-adapters-1.1.jar
> |-- commons-logging-api-1.1.jar
> |-- excalibur-logger-2.1.jar
> |-- log4j-1.2.13.jar
> |-- logkit-1.2.2.jar
>
> The logging for the simple servlet is:
> tree searcher/WEB-INF/lib/|grep log
> |-- commons-logging-1.1.jar
> |-- log4j-1.2.14.jar
>
> Now starting tomcat with only one application it is working fine as well
> when I "mv" the other app into tomcat there is no problem but as soon as
> I *restart* tomcat. BAAANGG!!
>
> Oct 17, 2007 4:22:07 PM org.apache.catalina.core.StandardContext
> loadOnStartup
> SEVERE: Servlet /searcher threw load() exception
> org.apache.commons.logging.LogConfigurationException: User-specified log
> class 'org.apache.commons.logging.impl.LogKitLogger' cannot be found or
> is not useable.
> at
> org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:798)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:601)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:333)
> at
> org.apache.commons.logging.LogFactory.getLog(LogFactory.java:664)
> at
> org.springframework.web.servlet.DispatcherServlet.<clinit>(DispatcherServlet.java:242)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at java.lang.Class.newInstance0(Class.java:350)
> at java.lang.Class.newInstance(Class.java:303)
> at
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1104)
> at
> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:981)
> at
> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4045)
> at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4351)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
> at
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:920)
> at
> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:883)
> at
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492)
> at
> org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
> at
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
> at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
> at
> org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
> at
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
> at
> org.apache.catalina.core.StandardService.start(StandardService.java:516)
> at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:566)
> 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:585)
> at
> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
> at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
>
> I actually do not understand this exception at all since I do not use
> LogKitLogger in the "searcher servlet". In my servlet I have something
> like:
>
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
>
> /**
> * Simple wrapper class to easier debug/log.
> *
> */
> public class LoggableSearcher {
>
> protected final Log log =
> LogFactory.getLog(this.getClass().getCanonicalName());
>
> public LoggableSearcher() {
> super();
> }
>
> }
>
> Which I then extend with a Spring Controller.
> public class SearchController extends LoggableSearcher implements
> Controller {
> ...
> }
>
> I am looking for a solution for a while now but actually have not found
> any solution only reports about similar problems.
>
> Can somebody please give me some hints what the problem is and how I can
> fix it?
>
> Any input is highly appreciated.
>
> salu2
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org