Permalink to this page: https://cwiki.apache.org/confluence/x/3SolBg
Preface
This page addresses various issues related to running Tomcat on a Windows platform. Please see the UsefulLinks for more links related to Windows.
...
- Why do I get Out of Environment Space?
- When I start up tomcat (or when it is running), I get the error java.lang.IllegalMonitorStateException: current thread not owner
- Can I turn off case sensitivity?
- Can I use NTLM authentication?
- I want to redeploy web applications, how do I prevent resources from getting locked?
- Can I use UNC paths?
- Why can't Tomcat see my mapped drive when running as a service?
- Why aren't access logs showing up in Tomcat on Vista?
- Why do I get a "HTTP/1.x 400 No Host matches server name" error when I change the "webapps" folder in Tomcat on Vista?
- How do I add or customize a Windows Service for Tomcat?
- What are tomcat6wtomcat9w.exe/tomcat6tomcat9.exe (or tomcat7w.exe/tomcat7.exe etc..) ?
Answers
| Anchor | ||||
|---|---|---|---|---|
|
Check the Tomcat README, and this link
| Anchor | ||||
|---|---|---|---|---|
|
That weird issue was observed many years ago and now is a history. See the Tomcat Bug Report #13723 and Sun Bug Parade report #4776385 for the answer.
| Anchor | ||||
|---|---|---|---|---|
|
It is possible in Tomcat 6 and earlier, but not recommended.
| Anchor | ||||
|---|---|---|---|---|
|
Yes.
- Waffle/JNA (obsolete)
- Tomcat SPNEGO (obsolete)
- SPNEGO SF
- Jespa (commercial)
- Tomcat IIS Connector
- Samba JCIFs (obsolete, no NTLMv2)
| Anchor | ||||
|---|---|---|---|---|
|
Most locking issues will occur with JARs from /WEB-INF/lib, and are usually caused by access through URLs. Tomcat has mechanisms to allow avoiding locking.
Since Tomcat 5.0, a mechanism exists to prevent locking when accessing resources using the getResource method of the URLClassLoader. Many applications, such as Xerces, do not set the use of caching to false before opening the URL connection to a JAR file, and that causes locking. In Tomcat 5.5, this mechanism is disabled by default (as it has a non negligible influence on startup times, and is often useless), and can be enabled using the antiJARLocking attribute of the Context element. If getResource call occurs, resources inside the JARs will be extracted to the work directory of the web application. There is an alternative to this since Tomcat 6.0.24: you can configure a JreMemoryLeakPreventionListener in your server.xml and it will set the URL connection caching to be off by default.
There is another lock prevention mechanism in Tomcat 5.5 (antiResourceLocking attribute), which will cause the web application files to be copied to the temp folder and run from this location. This has a larger impact on web application startup times, but obviously prevents locking on all resources of the web application. This also allows more flexible management operations as none of the web application resources will be locked, even while the web application is running (as a special note, when making changes to JSPs without reloading the application, the changes have to be duplicated to the path where the web application resources have been copied in the temp folder).
| Anchor | ||||
|---|---|---|---|---|
|
Yes. Make sure that the user that Tomcat is running as is able to access the path. This is particularly important when running Tomcat as a service since the local service account will not have the necessary permissions.
| Anchor | ||||
|---|---|---|---|---|
|
The mapped drives are part of a user's profile and they are not used when running as a service. You should be OK with UNC paths.
| Anchor | ||||
|---|---|---|---|---|
|
By default, the Tomcat Windows Service installer attempts to place Tomcat inside the "Program Files" folder. Default Vista folder permissions cause various logging functions (though mysteriously not every log function) to fail silently. It is best to change Tomcat's install folder to something like "C:\Tomcat". This issue can be hard to spot because by default the access logs are not enabled and the example webapps work just fine.
| Anchor | ||||
|---|---|---|---|---|
|
By default, the Tomcat Windows Service installer attempts to place Tomcat inside the "Program Files" folder. Default Vista folder permissions conflict with the contents of the "webapps" folder, can case a blank page to come up when attempting to access the webapp. By using a HTTP Header inspector like "Live HTTP Headers" you can see a slightly more descriptive error message. It is best to change Tomcat's install folder to something like "C:\Tomcat". This issue can be hard to spot because by default the example webapps work just fine.
| Anchor | ||||
|---|---|---|---|---|
|
Tomcat uses the Apache Commons Daemon. You can read its documentation at http https://commons.apache.org/proper/commons-daemon/procrun.html As a short example, you can create a new Windows Service with the full version number in its name like this:
...
See also the service.bat file that comes in the *-windows-<arch>.zip distributives distributions of Tomcat.
| Anchor | ||||
|---|---|---|---|---|
|
...
tomcat9w.exe/
...
tomcat9.exe (or tomcat7w.exe/tomcat7.exe etc..)?
Questions on this topic come regularly at various levels. So this is a longish explanation meant basically for real Tomcat/Windows beginners. Apologies in advance for any shortcuts and approximations. You can sort this out by yourself according to your own needs.
...
The Apache "procrun" software project provides such a wrapper program. Its original documentation can be found here: http https://commons.apache.org/proper/commons-daemon/procrun.html. But this documentation is more of the "reference" type : good for someone who already knows what they are looking for, but not very good as an introduction; and it doesn't explain what tomcat7w.exe (or tomcat6w.exe or tomcat5w.exe) and tomcat7.exe (or tomcat6.exe or tomcat5.exe) really are. From there this FAQ entry.
...
One more thing: because the tomcat7.exe wrapper program actually "runs" the JVM, it must match the type of JVM that it runs, in terms of 32bit/64bit version. If you try to start a 64-bit JVM with a 32-bit tomcat7.exe, it won't work, and vice-versa. This is why there are several versions of the tomcat7.exe program: one 32-bit version and two one 64-bit version for two different 64-bit CPU architectures.
One of the The 64-bit versions version is for the widely used "AMD64"/"x86-64" architecture (x64). If you have a 64-bit processor it is likely that you want to use this one. Another one is (Some time ago there was another 64-bit version provided as well: the one for the "Intel Itanium" architecture "IA-64" which is more rare (i64). It was discontinued). You must install and use the correct one matching the JVM that you are using.
The Tomcat Service installer for Windows normally bundles all three versions of the service wrapper and selects one for you automatically, according to the JRE instance that you selected during installation. The ZIP distributives distributions of Tomcat contain only one version of the program, so you have to select the correct distributive to download (*-windows-x86.zip , or *-windows-x64.zip or *-windows-i64.zip).