THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
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
Preface
The will address various windows issues. Please see the Other Resources Link UsefulLinks for more links related to Windows.
Questions
- 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 tomcat9w.exe/tomcat9.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 of Tomcat.CategoryFAQ-<arch>.zip distributions of Tomcat.
| Anchor | ||||
|---|---|---|---|---|
|
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.
Java is a programming language designed to be "compile once, run anywhere". The idea is that when you compile a java program, the java compiler creates a "java bytecode" version of your java program, and this bytecode version can be run by any Java Virtual Machine (a JVM) which runs on any platform (iow under any operating system) where such a JVM has been ported. Microsoft Windows is such a platform, and there exists a JVM which runs on it. Tomcat is a java application, and when it runs on a Windows platform, what really runs as a Windows process is the JVM, which in turn executes the bytecode of the compiled Tomcat application.
Because the JVM has to run on many different platforms, it cannot be too specific for each platform. For example under Windows, the JVM is not very good at running as a Windows Service. Windows Services are supposed to respond in specific ways to "signals" (or "messages") sent by the Windows Services Manager, and the Windows JVM does not really implement the code needed to do that.
To make the JVM really capable to respond to such Windows signals/messages, one solution is to run the JVM inside of a "wrapper" program which is written in such a way that it does respond properly to Windows signals/messages, passes these signals to the JVM in a way which the JVM understands, and returns appropriate messages to the Windows Services Manager to indicate that the JVM started or stopped properly.
The Apache "procrun" software project provides such a wrapper program. Its original documentation can be found here: 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.
tomcat7.exe is in fact a renamed copy of the "prunsrv" program from the procrun project. This is the "wrapper" mentioned previously. When you install Tomcat as a Windows Service, what you are really installing is the prunsrv program, renamed as tomcat7.exe. This is the program that Windows knows as being the Tomcat Service, and it will send to this program the messages telling the Tomcat Service to start or stop. In turn, tomcat7.exe will run the JVM, and it will translate for the JVM these Windows messages. And the JVM will run Tomcat. Through this subterfuge, Windows will see a Windows Service application named "Apache Tomcat", which runs as a Windows Service and which responds properly to Windows Service messages.
So what is tomcat7w.exe then ? It is a renamed version of the procrun "prunmgr" program. This is in fact a simple graphical Windows Registry editor, which is able to set and modify specific keys and values in the Registry; and these specific keys/values are the ones which are read by tomcat7.exe (the JVM wrapper program mentioned earlier).
When tomcat7.exe launches a JVM, it can pass to this JVM a number of "command-line options" (things such as "-Xmx", "-Dxxx" and so on). To know which command-line options to pass, it reads specific keys/values in the Windows Registry. And these keys/values are the ones which you can set/modify via the tomcat7w.exe program.
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 one 64-bit version.
The 64-bit 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. (Some time ago there was another 64-bit version provided as well: the one for the "Intel Itanium" architecture "IA-64" (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 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).