Um.
Let's back up and make sure everyone knows what they are talking about. Too many assumptions seem to be flying about.
FIRST. To run a servlet, you need a WAR. Forget all this stuff about directory-this and file-that. Think of the webapp as a
unit, since that's what it is in the
J2EE standard. The WAR has a certain structure and certain components that must be properly set up. The directories and files are simply how the WAR appears in "exploded" form. A J2EE-compliant WAR is a special form of JAR file, which, in turn is a special form of ZIP file. If the WAR is malformed, it may not deploy, and even if it does deploy, it may not run properly.
I'm not even going to talk about IDEs. IDEs can really mess things up here, so I'm going to talk stand-alone Tomcat and how it works.
When running Tomcat, WARs can live anywhere in the filesystem that there's no conflict. Meaning, for example, that I wouldn't keep a WAR file under TOMCAT_HOME/logs, for example. The default location, however, is the TOMCAT_HOME/webapps directory. A WAR can be in standard J2EE format (zipped) or it can be exploded. You can map a URL context path to that war by using a Tomcat
Context element and that can be located in several different places, one of which in a file with the same name as the context plus ".xml" and located in the TOMCAT_HOME/conf/Catalina/localhost directory. The official term for a Context is "server-specific Deployment Descriptor". It's paired with the "server-independent Deployment Descriptor", better known as WEB-INF/web.xml to define how the webapp will be deployed.
If you do not define an explicit Context, one will be synthesized. If you drop a WAR into the TOMCAT_HOME/webapps directory, the synthesized Context will have a context name that's the same as the WAR name. By default, if you drop a WAR file into TOMCAT_HOME/webapps, Tomcat will automatically explode it, creating a directory with the same name as the WAR file (minus the ".war") to hold the exploded contents. Or you can simply copy or explode a directory into the webapps directory yourself as long as you follow the same structural constraints.
Here comes the tricky part. You dropped in a WAR file. Tomcat exploded it to make a WAR directory. What happens next?
It's pretty intuitive that the exploded WAR is the copy that will be executed, but what about when you drop in an updated WAR file? Answer:
nothing. The exploded WAR is the definitive copy, so to get it to update, you'd have to delete it and let Tomcat explode the new WAR file (or explode it yourself). Tomcat will ignore a WAR file if there's an exploded WAR of the same name, even if the WAR file is newer.
For best results, then, do the following when deploying a new version of a WAR:
1. Delete the WAR directory
2. Delete the contents of TOMCAT_HOME/work
3. Delete the contents of TOMCAT_HOME/temp
4. Delete the contents of TOMCAT_HOME/logs
Do this while Tomcat is stopped. If you prefer not to perform wholesale destruction on the other directories, you can delete just their subtrees applying to the webapp you're developing, but there's never going to be anything in there that cannot be recreated automatically as the app runs, so it's just as easy to clear them entirely.
NOW that we have the what's-where covered, for a specific servlet in the WAR:
The mapping of an incoming servlet to a URL is done in stages, which I explained the other day in the Tomcat forum. You have the protocol/server/port part (
http://www.javaranch.com:8080), the context path part ("/mywebapp") defined by the Context, as described about (this tells which webapp within the server handles the request), and the servlet-mapping part.
Servlets are mapped in the web.xml via a 2-level abstraction. First you map the URL path component to a logical servlet name, then you map the logical servlet name to a specific servlet. The servlet is identified by its fully-qualified classname, meaning that "MyServlet" isn't enough. It would be something like "com.javaranch.demoapp.MyServlet", if the package name is com.javaranch.demoapp, and as always in
Java (even in Windows), upper/lower case MUST match exactly and you don't include the ".class" or ".java" on the classname, since Java already knows about that part.
So given a Servlet URL mapping of "/growflowers" in web.xml mapped to a logical servlet name of "Test App" (spaces are OK here), mapped to "com.javaranch.demoapp.MyServlet", all bundled under a context (WAR) pathname of "/mywebapp", the URL that should invoke the servlet would be in the form:
