We're running Tomcat 4.1.30 on Windows 7 and Windows server 2008 to support Panscopic Scopeserver24. The system has been running under Java 1.4.2 and we're now starting to get Out Of Memory errors on large reports. My understanding is that Java code is portable since it's compiled to bytecode, so I'm hoping that I can get this system to run under the latest 64 bit version of java - 1.7.0.
I've uninstalled Java 1.4.2 and installed 1.7.0, but cannot get the tomcat service to start. I did notice in Tomcat's registry settings (HKLM\SYSTEM\CurrentControlSet\services\Apache Tomcat\parameters that some jar files referenced here had been placed in different directories. I fixed that in the registry, but the service would still not start.
in a DOS box:
Net Start "Apache Tomcat"
The Apache Tomcat service is starting.
The Apache Tomcat service could not be started.
The service did not report an error.
I don't see any file in Tomcat's log file directory.
Any suggestions on how to get tomcat started or hoe to debug the issue would be appreciated.
I've found an Event Log error reported by Apache Tomcat - Could not load the Java Virtual Machine.
I've double checked the PATH, rebooted (to ensure that the services does not have an out of date path), and double checked the JVM Library key in the registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Apache Tomcat\Parameters\JVM Library. They all point to the correct locations for Java.exe or JVM.dll.
java -version reports:
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)
I've also check the other relevant looking registry entries:
JVM Option Number 1: -Djava.class.path=C:\Program Files\Tomcat\jakarta-tomcat-4.1.30\bin\bootstrap.jar;C:\Program Files\Java\jdk1.7.0_40\lib\tools.jar
JVM Option Number 2: -Dcatalina.home=C:\Program Files\Tomcat\jakarta-tomcat-4.1.30
And these point to correct locations.
So why would the service "not be able to load the Java Virtual Machine"???
Is the refernce to Mixed Mode in the java version report a clue? What does this mean?
To make a clean start, I suggest to uninstall Java and Tomcat, remove all registry entries that have anything to do with either, and then start from scratch by installing Java 7 and Tomcat 7. Just as Java 1.4 is way obsolete, so is Tomcat 4. It's quite possible that nobody has ever tried running Tomcat 4 with Java 7 (and that for some reason it simply doesn't work.)
T=hanks. I've already done that and it works. But my real problem is that Panscopic is no longer a supported product, and that doesn't run under Tomcat 7. So, until we replace the whole setup, I'm stuck with Tomcat 4. I feel that I'm not far from getting this working, and after all the Java philosophy is that software should run under any JVM. So if only I could find out why the JVM isn't loading, I could solve my immediate problem whhile I look for a replacement of the whole setup.
I see. Well, it doesn't have to be Tomcat 7. Try Tomcat 6 or 5, too. And Java 6. Just like Java code generally runs in newer JVMs, so web apps generally run in newer servlet containers. Unless the product depends on version-specific bugs or internals, of course. It seems that company should be able to at least provide information on which JVM/Tomcat is known to work, even if they don't support it any more. Panscopic is an early version of the JasperReport server, from what I gather?
Since you can't start Tomcat as a service, can you start it with the scripts in its "bin" directory?
I'm not sure that any Tomcat older than Tomcat 5.5 (which is end-of-life as well) can support 64-bit operation. There was a radical shift in both Tomcat and JVM architectures in that release.
Life would be simpler if you'd used Microsoft technology. Since Microsoft doesn't support deprecation your app would be well and truly broken by now and you wouldn't be wasting your time.
While in theory you can run Java 7 in Java 1.4 compatibility mode completely transparently, there's always the chance of the odd glitch.
And even if there wasn't, 1.4 compatibility might well mean that it downshifts to 32-bit operation. Just because JVMs are backwards compatible doesn't mean that it's a total free-for-all in both directions. The word "enum" became a reserved word in Java 5, for example.
Sources may include data from the Fakebook Research Foundation with support from Gargle University
Why am I so drawn to cherry pie? I can't seem to stop. Save me tiny ad!