Note that a webapp doesn't HAVE to be located in the $CATALINA_BASE/webapps directory. In fact, many of mine are not. When testing, I run straight from my development directory, and I often have special production directories external to Tomcat that hold production WARs.
Beyond that, the actual deployOnStartup determines whether a Context will be created or installed for the webapps that are physically present in $CATALINA_BASE/webapps. And whether old WARs will be deleted and new WARs exploded when Tomcat starts up. As opposed to simply using previously-deployed WARs.
Normally I don't override the default value of deployOnStartup and I'm perfectly happy.
An IDE is no substitute for an Intelligent Developer.
I got your point. But in this case i wanted to set it as false
I have 2 tomcat running on the same machine. Procedure as follows:
1) Starting my application
2) Starting first tomcat on port 8080 which register with application
3) I start another instance of tomcat on the same PORT 8080. ---> THIS WILL REPLACE THE REGISTRATION DONE WITH FIRST TOMCAT, EXISTS BY THROWING PORT BIND EXCEPTION
This is because deployOnStartup is set to TRUE, where all the application war files getting deployed before tomcat startup. Its deploying and replaceing the first tomcat instance and throwing port bind.
So i wanted to set this to FALSE, So that deploy happens if tomcat starts up properly (In this case Port bind comes during startup only, so no way it goes to next step which is deployment -> This never replaces registration with application )
Time difference is totally different in both the cases:
deployOnStarup=true: --> Order deployment and tomcat startup.
Tomcat starts in 8 secs.
deployOnStarup=false: --> Order Tomcat startup and Deployment.
Tomcat starts in 15 secs.
Any idea why this time gap? Is there any specific deployment handling in case of deployOnStartup is set to false?
So you mean, if Tomcat A is started on port 8080 and you start another instance on the same port then the applications deployed on Tomcat A are affected? I haven't heard of that before. What problems are you seeing with the deployed applications?
Playing with the deployOnStartup isn't going to achieve much in this case - how would you even handle this if it was some other server like JBoss which would try to start on the same port where Tomcat is already running.
Two applications cannot listen on the same TCP/IP port.
This is not a Tomcat problem. This is not a Java problem. This is a fundamental constraint of the TCP/IP architecture.
For any give OS instance one and ONLY one process can own a TCP/IP port. Attempts by any other process to open and listen on that port will fail. The OS will reject the open attempt.
In the case of Tomcat, Tomcat will not shut down if access is denied to a resource, but the resource will not be available for the life of the Tomcat JVM. Tomcat has no standard mechanism to go in later and acquire a listener port if it wasn't available at startup time. So the second Tomcat instance is effectively useless. At least in regard to any activity on port 8080.
Also, I think you are confusing "install" and "deploy". They are not the same thing.