I looked at this a little further...
On Wed, 2005-03-09 at 07:25 -0800, Anthony Green wrote:
> Now tomcat5 gets a lot further, and we hit something new....
>
> # cat /var/log/tomcat5/catalina.out
> Bootstrap: Class loader creation threw exception
> java.lang.NoClassDefFoundError: while resolving class: javax.management.MBeanServerFactory
> 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 org.apache.catalina.startup.Bootstrap.createClassLoader(java.lang.String, java.lang.ClassLoader) (Unknown Source)
> at org.apache.catalina.startup.Bootstrap.initClassLoaders() (Unknown Source)
> at org.apache.catalina.startup.Bootstrap.init() (Unknown Source)
> at org.apache.catalina.startup.Bootstrap.main(java.lang.String[]) (Unknown Source)
> at gnu.java.lang.MainThread.call_main() (/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: mx4j.log.Logger not found in gnu.gcj.runtime.SystemClassLoader{urls=[], parent=gnu.gcj.runtime.VMClassLoader{urls=[file:/usr/share/java/ext/com-sun-tools-doclets-Taglet-0.7.1.jar], 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.Class.forName(java.lang.String, boolean, java.lang.ClassLoader) (/usr/lib/libgcj.so.6.0.0)
> ...8 more
The tomcat5 startup script uses JPackage's rebuild-jar-repository script
to construct a directory of jar files for the server to use. One of
these is [jmxri].jar. So it symlinks to /usr/share/java/jmxri.jar,
which is itself a symlink since jmx appears to be managed by
alternatives. We eventually get to /usr/share/java/mx4j/mx4j-jmx.jar.
Unfortunately, this jar has external dependencies on other jar files
in /usr/share/java/mx4j. How is rebuild-jar-repository or tomcat5
supposed to know this? We end up with an incomplete jar repository,
which is causing this problem. Is there a good and simple solution to
this problem?
AG
