Bug 169709 - Exception on startup while resolving class: org.apache.catalina.startup.Bootstrap
Exception on startup while resolving class: org.apache.catalina.startup.Boots...
Product: Fedora
Classification: Fedora
Component: tomcat5 (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Devrim GUNDUZ
Depends On:
  Show dependency treegraph
Reported: 2005-10-01 14:43 EDT by Greg Douglas
Modified: 2008-01-05 08:45 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-05 08:45:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Modified Startup Script for Tomcat5 (12.57 KB, application/octet-stream)
2006-04-05 18:53 EDT, Greg Douglas
no flags Details

  None (edit)
Description Greg Douglas 2005-10-01 14:43:14 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
I am trying to get Tomcat5 to work with gcj, but it will not start.  I have installed the java-gcj-compat package, and my eclipse install work fine, but when I try to start the Tomcat5 service, I get the following message in the catalina.out logfile:

Exception in thread "main" java.lang.NoClassDefFoundError: while resolving class: org.apache.catalina.startup.Bootstrap
   at java.lang.VMClassLoader.transformException(java.lang.Class, java.lang.Throwable) (/usr/lib/libgcj.so.6.0.0)
   at java.lang.VMClassLoader.resolveClass(java.lang.Class) (/usr/lib/libgcj.so.6.0.0)
   at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.6.0.0)
   at java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader) (/usr/lib/libgcj.so.6.0.0)
   at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0)
Caused by: java.lang.ClassNotFoundException: javax.management.MBeanServer not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./,file:/usr/share/tomcat5/bin/bootstrap.jar,file:/usr/bin/build-classpath,file:./,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
   at java.net.URLClassLoader.findClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0)
   at java.lang.ClassLoader.loadClass(java.lang.String, boolean) (/usr/lib/libgcj.so.6.0.0)
   at java.lang.ClassLoader.loadClass(java.lang.String) (/usr/lib/libgcj.so.6.0.0)
   ...4 more

Have you encoutered this problem before?



Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Start the Tomcat5 server from the System Services gui. A pop-up indicates that the service started successfully.
2. Try using browser to access http://localhost:8080.  Connection is refused.
3. Look in /var/log/tomcat5/catalina.out, and I get the message pasted above.

Actual Results:  Exception pasted above appears in cataline.out logfile.

Additional info:

I upgraded from FC3, where I was using the Sun Java VM, and the Java-Sun-Compat package.  I removed all of the "java-compat" packages, and reinstalled java-gcj-compat.  I tried adding CATALINA_HOME to /etc/profile.  I currently have Java 1.5 installed, but my "alternatives" point to gcj, as does /usr/bin/java.  At the prompt, "java -version" refers to gcj.  Eclipse works fine.
Comment 1 Dan 2005-11-29 00:57:42 EST
For what it's worth: There is a bug in the packaging dependencies of tomcat5.
The error above should be fixed if you install the package:

The xml-commons package is installed, but the "apis" package is required and is
NOT installed. Not sure who to report this to at Fedora...but that fixed it for me.
Comment 2 Dan 2005-11-29 00:59:34 EST
Ack, sorry, I didn't read the error close enough, so I don't think your specific
error is related. Sorry for the noise.
Comment 3 Greg Douglas 2005-11-30 08:30:45 EST
Thanks for the feedback.  I just tried the recommendation and unfortunately, I
am still getting the problem described above.

Thanks anyways.
Comment 4 Greg Douglas 2006-04-04 10:30:30 EDT
I upgraded to FC5 yeasterday and tried to reinstall Tomcat5.  Unfortunately, I'm
still getting the same problem.  Here is the message in the Tomcat Log:

Exception in thread "main" java.lang.NoClassDefFoundError:
   at java.lang.Class.initializeClass (libgcj.so.7)
   at java.lang.Class.forName (libgcj.so.7)
   at gnu.java.lang.MainThread.run (libgcj.so.7)
Caused by: java.lang.ClassNotFoundException: javax.management.MBeanServer not
found in
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
   at java.net.URLClassLoader.findClass (libgcj.so.7)
   at java.lang.ClassLoader.loadClass (libgcj.so.7)
   at java.lang.ClassLoader.loadClass (libgcj.so.7)
   at java.lang.Class.initializeClass (libgcj.so.7)
   ...2 more
Comment 5 Rafael H. Schloming 2006-04-04 11:40:27 EDT
The classpath listed in the stack trace has the following entries:


Note the two file: urls referencing /usr/bin/build-classpath. This classpath is
generated by line 167 of /usr/bin/dtomcat5 which is this:

mx4j/mx4j-impl`:`/usr/bin/build-classpath mx4j/mx4j-jmx`

Note the two calls to /usr/bin/build-classpath, one with mx4j/mx4j-impl, and the
other with mx4j/mx4j-jmx. One of these should be returning
/usr/share/java/mx4j/mx4j-jmx.jar which contain the missing class. I have no
idea why in your case that is not happening. What happens if you manually run
the following command?

/usr/bin/build-classpath mx4j/mx4j-jmx

Also, could you post the output of this?:

rpm -V tomcat5 jpackage-utils
Comment 6 Greg Douglas 2006-04-04 12:36:14 EDT
If I run the command /usr/bin/build-classpath mx4j/mx4j-jmx, I get the following:


If I run rpm -V tomcat5 jpackage-utils, I get nothing, as below.

[root@atomic greg]# rpm -V tomcat5 jpackage-utils
[root@atomic greg]#

And yet both packages are indeed installed.

Comment 7 Rafael H. Schloming 2006-04-04 14:03:59 EDT
I'm still confused at the moment. Could you try the following commands as well
and send the output to me? (Please cut and paste for accuracy.)

sed 's@exec @exec /bin/echo @' /usr/bin/dtomcat5 > /tmp/dtomcat5
sh /tmp/dtomcat5 run

And for good measure:

rpm -qa tomcat5 jpackage-utils

Comment 8 Greg Douglas 2006-04-04 15:12:20 EDT
Hi Rafael.

Here is the output from the first:

[root@atomic greg]# sed 's@exec @exec /bin/echo @' /usr/bin/dtomcat5 > /tmp/dtomcat5
[root@atomic greg]# sh /tmp/dtomcat5 run
Using CATALINA_BASE:   /usr/share/tomcat5
Using CATALINA_HOME:   /usr/share/tomcat5
Using CATALINA_TMPDIR: /usr/share/tomcat5/temp
-Djava.endorsed.dirs=/usr/share/tomcat5/common/endorsed -classpath
error: JVM_LIBDIR /usr/lib/jvm-exports/java does not exist or is not a
directory:/usr/bin/build-classpath: error: JVM_LIBDIR /usr/lib/jvm-exports/java
does not exist or is not a directory -Dcatalina.base=/usr/share/tomcat5
-Dcatalina.home=/usr/share/tomcat5 -Djava.io.tmpdir=/usr/share/tomcat5/temp
org.apache.catalina.startup.Bootstrap start
[root@atomic greg]#

And here is the output from the second:

[root@atomic greg]# rpm -qa tomcat5 jpackage-utils

Comment 9 Greg Douglas 2006-04-05 14:56:13 EDT
I looked at the output above and noticed that the /usr/lib/jvm-exports/java did
not exist.  I created a symlink to the jre-gcj directory in the same jvm-exports
directory.  Now I get a new message in the logs. It appears to take longer to
run before crashing.  Also below is the output of the sed and sh commands above.
 They look clean now.

java.lang.NoClassDefFoundError: org.apache.catalina.core.StandardService
   at java.lang.Class.initializeClass (libgcj.so.7)
   at java.lang.Class.initializeClass (libgcj.so.7)
   at java.lang.Class.initializeClass (libgcj.so.7)
   at java.lang.Class.newInstance (libgcj.so.7)
   at org.apache.catalina.startup.Bootstrap.init (bootstrap.jar.so)
   at org.apache.catalina.startup.Bootstrap.main (bootstrap.jar.so)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.modeler.Registry
not found in
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}}}
   at java.net.URLClassLoader.findClass (libgcj.so.7)
   at java.lang.ClassLoader.loadClass (libgcj.so.7)
   at java.lang.ClassLoader.loadClass (libgcj.so.7)
   at java.lang.Class.initializeClass (libgcj.so.7)
   ...5 more

[root@atomic greg]# sed 's@exec @exec /bin/echo @' /usr/bin/dtomcat5 > /tmp/dtomcat5
[root@atomic greg]# sh /tmp/dtomcat5 run
Using CATALINA_BASE:   /usr/share/tomcat5
Using CATALINA_HOME:   /usr/share/tomcat5
Using CATALINA_TMPDIR: /usr/share/tomcat5/temp
-Djava.endorsed.dirs=/usr/share/tomcat5/common/endorsed -classpath
-Dcatalina.base=/usr/share/tomcat5 -Dcatalina.home=/usr/share/tomcat5
-Djava.io.tmpdir=/usr/share/tomcat5/temp org.apache.catalina.startup.Bootstrap start

Comment 10 Greg Douglas 2006-04-05 15:17:43 EDT
I then noticed from the output above that org.apache.commons.modeler.Registry
appears to be missing.  After a search on Google, it appears to be part of the
jakarta-commons-modeler.i386 package.  From the text below, it looks like I have
it installed.

jakarta-commons-modeler.i386             1.1-4jpp_6fc           installed
Matched from:
[greg@atomic ~]$ rpm -V jakarta-commons-modeler.i386
[greg@atomic ~]$
Comment 11 Greg Douglas 2006-04-05 15:47:10 EDT
It appears that the jakarta-commons-modeler jar is located in the directory
below.  Any idea why Tomcat5 is not seaching in this directory?

[greg@atomic ~]$ rpm -ql jakarta-commons-modeler.i386
[greg@atomic ~]$
Comment 12 Greg Douglas 2006-04-05 18:51:03 EDT
Success, I've been able to fix it.  I have added the parameter
"/usr/share/java/jakarta-commons-modeler-1.1.jar" to the CLASSPATH settings in
the startup script /usr/bin/dtomcat5

I have attached the script below.

Therefore there are 2 problems that should be dealt with:

1. The file /etc/tomcat5/tomcat5.conf refers to the location of the JRE as
/usr/lib/jvm-exports/java.  This may not exist for many users, particulary those
that have upgraded from earlier releases of FC.  Should it not point to
/usr/lib/jvm-exports/jre-gcj instead?

2. We need to add another parameter
("/usr/share/java/jakarta-commons-modeler-1.1.jar") to the CLASSPATH settings in
the startup script /usr/bin/dtomcat5.  Please see the attached file below and
search for GJD.

Comment 13 Greg Douglas 2006-04-05 18:53:50 EDT
Created attachment 127376 [details]
Modified Startup Script for Tomcat5
Comment 14 Rafael H. Schloming 2006-04-05 20:03:10 EDT
I'm glad you've been able to work around the problem, but I'm pretty sure the
issues you're seeing are problems with the upgrade, and you may run into more
problems down the line.

On a clean install /usr/lib/jvm-exports/java is a symbolic link to
/etc/alternatives/java_sdk_exports. Similarly the commons-modeler jar shouldn't
need to be in the CLASSPATH because it is linked to from
/usr/share/tomcat5/server/lib, and should be picked up by the catalina class loader.

I'm guessing if you run the following command:

ls /usr/share/tomcat5/server/lib

You'll have some missing or broken symbolic links relative to a clean fc5
install. Can you send me the output of the above command?

When I have a free machine I'm going to try to directly reproduce the problems
you've run into by testing the upgrade path you outlined in your initial report.
Comment 15 Greg Douglas 2006-04-06 07:31:51 EDT
Thanks Rafael.

Here is the output to the ls command:

[root@atomic greg]# ls /usr/share/tomcat5/server/lib
[catalina-ant5].jar       [commons-fileupload].jar  servlets-invoker.jar
catalina-ant-jmx.jar      [commons-logging].jar     servlets-ssi.renametojar
catalina-cluster.jar      [commons-modeler].jar     servlets-webdav.jar
catalina.jar              [eclipse-ecj].jar         tomcat-ajp.jar
catalina-optional.jar     [jaas].jar                tomcat-apr.jar
catalina-storeconfig.jar  [mx4j][mx4j].jar          tomcat-coyote.jar
[commons-beanutils].jar   [regexp].jar              tomcat-http.jar
[commons-digester].jar    servlets-cgi.renametojar  tomcat-jkstatus-ant.jar
[commons-el].jar          servlets-default.jar      tomcat-util.jar
[root@atomic greg]#

Comment 16 Devrim GUNDUZ 2008-01-05 08:45:15 EST
Cannot reproduce in current releases . Closing.

Note You need to log in before you can comment on or make changes to this bug.