You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2003/02/24 05:14:16 UTC

DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888

WebappClassLoader: Lifecycle error : CL stopped





------- Additional Comments From hoju@visi.com  2003-02-24 04:14 -------

Note sure if this is still being investigated or not but I noticed some pretty
bad behavior related to this bug under Tomcat-5.  The symptom is triggered the
same way for both Tomcat-4.1.x and tomcat-5 (with slight differences...read on).
 However, after getting the lifecycle error under Tomcat4, the context continues
to work.  After gettting the error under Tomcat5, the context quits working. 
The manager app reports it as not being started.

Here is how I reproduce the problem...

1.  Start Tomcat (4 or 5)
2.  Use the catalina-ant task to install/remove my app.  I go through the
following separate steps...
    ant catalina-install
    ant catalina-remove catalina-install
    ant catalina-remove catalina-install
    ant catalina-remove superclean catalina-install

The first 3 separate steps result in the context starting just fine.  However,
after the fourth step, the context fails to start.  Note that "superclean"
cleans up everything forcing a full clean rebuild.

I actually am not getting the "INFO: Lifecycle error : CL stopped" error unless
I do Log4j configuration.  However, I've somewhat ruled out Log4j as the culprit
because, although I don't get said error printed out when I don't explicitly
configure Log4j, I get the same behavior of the context not starting after the
4th step in either case.  Doing the configure must just trigger the code that
actually prints out that debugging where that same debugging code isn't
triggered otherwise.

Below is what is printed out in stdout.log in Tomcat5 when I do Log4j
configuration.  Notice that, somewhat curiously, the number of classloader
errors matches the number of times that the app was installed/removed (not
including the initial install).  Also note that I end up with an
"java.lang.IncompatibleClassChangeError:
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl" error in Tomcat5 where in
Tomcat4, I get   "javax.xml.parsers.FactoryConfigurationError: Provider
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found" ...


Starting service Tomcat-Standalone
Apache Tomcat/5.0
Configuring GlobalOR from File: WEB-INF/object-repository.xml
Enhydra Java Application Server
Copyright 1997-2000 Lutris Technologies, Inc.
All rights reserved.
Configuring GlobalOR from File: WEB-INF/object-repository.xml
Enhydra Java Application Server
Copyright 1997-2000 Lutris Technologies, Inc.
All rights reserved.
Configuring GlobalOR from File: WEB-INF/object-repository.xml
Enhydra Java Application Server
Copyright 1997-2000 Lutris Technologies, Inc.
All rights reserved.
Feb 23, 2003 9:00:25 PM org.apache.catalina.loader.WebappClassLoader
findResourceInternal
INFO: Lifecycle error : CL stopped
java.lang.IncompatibleClassChangeError:
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
	at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1199)
	at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1159)
	at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:93)
	at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:172)
	at
javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93)
	at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:644)
	at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:616)
	at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:584)
	at org.apache.log4j.xml.XMLWatchdog.doOnChange(DOMConfigurator.java:815)
	at org.apache.log4j.helpers.FileWatchdog.checkAndConfigure(FileWatchdog.java:80)
	at org.apache.log4j.helpers.FileWatchdog.run(FileWatchdog.java:99)
Feb 23, 2003 9:00:25 PM org.apache.catalina.loader.WebappClassLoader
findResourceInternal
INFO: Lifecycle error : CL stopped
java.lang.IncompatibleClassChangeError:
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
	at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1199)
	at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1159)
	at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:93)
	at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:172)
	at
javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93)
	at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:644)
	at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:616)
	at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:584)
	at org.apache.log4j.xml.XMLWatchdog.doOnChange(DOMConfigurator.java:815)
	at org.apache.log4j.helpers.FileWatchdog.checkAndConfigure(FileWatchdog.java:80)
	at org.apache.log4j.helpers.FileWatchdog.run(FileWatchdog.java:99)
Feb 23, 2003 9:00:26 PM org.apache.catalina.loader.WebappClassLoader
findResourceInternal
INFO: Lifecycle error : CL stopped
java.lang.IncompatibleClassChangeError:
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
	at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1199)
	at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1159)
	at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:93)
	at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:172)
	at
javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93)
	at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:644)
	at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:616)
	at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:584)
	at org.apache.log4j.xml.XMLWatchdog.doOnChange(DOMConfigurator.java:815)
	at org.apache.log4j.helpers.FileWatchdog.checkAndConfigure(FileWatchdog.java:80)
	at org.apache.log4j.helpers.FileWatchdog.run(FileWatchdog.java:99)
Configuring GlobalOR from File: WEB-INF/object-repository.xml
Enhydra Java Application Server
Copyright 1997-2000 Lutris Technologies, Inc.
All rights reserved.
Configuring GlobalOR from File: WEB-INF/object-repository.xml
Enhydra Java Application Server
Copyright 1997-2000 Lutris Technologies, Inc.
All rights reserved.


BTW, I am using Log4j-1.2.8 in WEB-INF/lib and have removed the Xerces that
comes with Barracuda in favor of Xerces-1.4.4 in common/endorsed because,
currently, XMLC-2.1 (xmlc.enhydra.org) requires that version of Xerces.  I have
noticed no issues with this setup other than when I do a clean build after
having installed the app in Tomcat.  Removing the app, then doing a clean build,
and then installing it again is when I get the bad behavior...and, of course,
worse behavior in Tomcat5.

So, does this help?  Any new ideas on why this might be happening?  Any fixes in
the works?

Jake

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org