Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification.
The "FAQ/Windows" page has been changed by KonstantinKolinko. The comment on this change is: Updated. http://wiki.apache.org/tomcat/FAQ/Windows?action=diff&rev1=6&rev2=7 -------------------------------------------------- <<Anchor(Q2)>>'''When I start up tomcat (or when it is running), I get the error {{{java.lang.IllegalMonitorStateException: current thread not owner}}}''' - That is weird - but solved.(?) See the [[http://issues.apache.org/bugzilla/show_bug.cgi?id=13723|Tomcat Bug Report]] and [[http://developer.java.sun.com/developer/bugParade/bugs/4776385.html|Sun Bug Parade report]] for the answer. + That weird issue was observed many years ago and now is a history. See the [[http://issues.apache.org/bugzilla/show_bug.cgi?id=13723|Tomcat Bug Report #13723]] and [[http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4776385|Sun Bug Parade report #4776385]] for the answer. <<Anchor(Q3)>>'''Can I turn off case sensitivity?''' - [[http://tomcat.apache.org/tomcat-4.1-doc/config/resources.html|Yes]] + It is [[http://tomcat.apache.org/tomcat-6.0-doc/config/context.html|possible]] in Tomcat 6 and earlier, but not recommended. <<Anchor(Q4)>>'''Can I use NTLM authentication?''' @@ -34, +34 @@ <<Anchor(Q5)>>'''I want to redeploy web applications, how do I prevent resources from getting locked?''' - Most locking issues will occur with JARs from /WEB-INF/lib, and are useally caused by access through URLs. Tomcat has mechanisms to allow avoiding locking. In Tomcat 5.0, a mechanism exists to prevent locking when accessing resources using the getResource method of the URL classloader (many applications, such as Xerces, do not set the use of caching to false before opening the URL connection, causing locking). If such a call occurs, resources inside the JARs will be extracted to the work directory of the web application. 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. 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 JSPs without reloading the application, the changes has to be duplicated to the path where the web application resources have been copied in the temp folder). + 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 [[http://tomcat.apache.org/tomcat-6.0-doc/config/context.html|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 [[http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/core/JreMemoryLeakPreventionListener.html|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(Q6)>>'''Can I use UNC paths?''' @@ -56, +60 @@ Tomcat uses the Apache Commons Daemon. You can read its documentation at http://commons.apache.org/daemon/procrun.html As a short example, you can create a new Windows Service with the full version number in its name like this: - {{{bin\tomcat6.exe //IS//tomcat6018 --DisplayName "Apache Tomcat 6.0.18"}}} + {{{bin\tomcat6.exe //IS//tomcat6026 --DisplayName "Apache Tomcat 6.0.26"}}} + See also the `service.bat` file that comes in the `*-windows-<arch>.zip` distributives of Tomcat. + --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
