This is a digest of what I've sent to the Tomcat Users List over the
past eight hours or so; I'm hoping somebody here might have some insights.
I'm trying to bring up Tomcat on a customer's AS/400. It's at the same
OS release as our own box, and Java 6 was just installed on it, sometime
this past week.
I get this exception in catalina.out:
java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina
at java.net.URLClassLoader.findClass(URLClassLoader.java:419)
at java.lang.ClassLoader.loadClass(ClassLoader.java:643)
at java.lang.ClassLoader.loadClass(ClassLoader.java:609)
at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:235)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425)
and this from stdout:
Using CATALINA_BASE: /wintouch/tomcat
Using CATALINA_HOME: /wintouch/tomcat
Using CATALINA_TMPDIR: /wintouch/tomcat/temp
Using JRE_HOME: /QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit
Using CLASSPATH: /wintouch/tomcat/bin/bootstrap.jar:/wintouch/tomcat/bin/tomcat-juli.jar
Tomcat started.
which is exactly the same as what comes out of STDOUT when we launch
Tomcat on our own box.
The customer box (an AS/400 at V6R1) is, according to RELEASE-NOTES, on
7.0.56. Our box (another AS/400 at V6R1) is on 7.0.54. We have another
customer box (another AS/400, this one at V7R1) that is running 7.0.56
just fine.
I wiped out the /wintouch/tomcat directory (same convention we use at
all of our Tomcat installations), re-unzipped it (as always, using JAR
from an interactive QSHELL session), and tried to launch it without
doing any of our usual configuration changes (e.g., enabling SSL,
setting up a user for Manager). It still crashed exactly the same way.
I found some interesting joblog messages (especially after launching
startup.sh from an interactive QSHELL session) that had me checking
public authorities to JARs, but after resolving those messages, Tomcat
continues to crash on takeoff, with exactly the same exception as before.
We have a CL program to launch Tomcat in a batch job; it leaves the
environment variables in place, that it set before launching the batch
job, where they, at least in theory, should be visible to an interactive
QSHELL session. Attempting to call /wintouch/tomcat/bin/startup.sh
produced the same results as the CL program.
A user on the Tomcat list suggested that I add "-verbose:class" and/or
"-Dibm.cl.verbose=ClassToTrace" to the JVM options. I added them to the
JAVA_OPTS environment variable and called startup.sh again; still the
same results.
Another user suggested checking for PTFs; we'd already asked somebody at
the customer site to do so.
--
James H. H. Lampert
midrange.com
