Make sure that:
- you type a trailing slash http://host/tomcat7/, not
http://host/tomcat7.
you have a AJP 1.3 connector listen on port 8009 in server.xml:
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
If it still doesn't work, I suggest you turning on debug and take a look at mod_jk.log.
EDIT:
If you use:
JkMount /tomcat7/* worker1
and access via http://host/tomcat7, I'm sure you will get the Apache 404 error.
You can specify JkMount in a Virtual Host section which you want:
<VirtualHost *:80>
ServerName xx
ServerAdmin xx
JkMount /tomcat7 worker1
JkMount /tomcat7/* worker1
</VirtualHost>
We have observed this with a long-running (but not Tomcat) Java app that runs as a Windows service. We create it as a Windows service with the 'procrun' mechanism in Apache Commons Daemon, which is the same way the Tomcat Windows service works.
From hints of other reports of this, it seems like the Java update process moves/renames files as part of upgrading to the new version. There might be one or two renames left to do when the install finishes, and those renames are supposed to happen after a reboot. But if there's a long-running Java app running at the same time as the update is taking place, that app will have various Java libs and exe's (like the main jre.exe) locked, and the Java update fails.
One symptom of this is to open a command window and type "java -version". If you get the noclassdeffound error for java/lang/Object, it's a pretty good bet that the combination of a JDK upgrade with a long-running Java app has left you with a corrupt JDK/JRE.
We have found two workarounds: (1) reinstall the app; (2) reinstall Java. (1) usually works for us because we have an installer for the app which will also install a clean version of Java if required. Sometimes even that fails, though, with the message "The jar-file 'reach-stream-installer-izpack.jar' could not be executed." (IzPack being the automated installer tool we use). In this case we fall back to (2).
Neither workaround is very nice. It's a shame that the automated JDK update facility provided by Java breaks our application.
Have you made any progress with this since your original posting?
Best Answer
I had the same problem, and could find a workaround. I don't know if it will work for you, though, since the OS is different (Windows Server 2008).
Steps:
First delete the tomcat service with "bin\tomcat7.exe //DS/Tomcat7".
Now, disable UAC.
Install the Tomcat service again with the command "bin\service.bat install"
Start the service.
If you want (and probably will), enable UAC again.
Since I successfully installed and started the Tomcat service, I did not need to disable UAC again.
The advice to disable UAC is present Tomcat 7 documentation, located at "http://tomcat.apache.org/tomcat-7.0-doc/windows-service-howto.html"