Your terminology makes me suspect you may not really understand what you're doing, so I'll go into pedantic mode.
You do NOT deploy a "J2EE project". You deploy a web application. Web applications must have a particular structure in order to operate successfully. Of the available structures, Tomcat supports only one: the Web Application Archive (WAR) format.
A WAR is both a file format (it's an extended JAR, which, is in its own turn an extended ZIP), and a directory structure (for example, you have the "magic" WEB-INF directory). In strict J2EE, the WAR is a single file, but Tomcat also allows you to unzip ("explode") a WAR and use the resulting directories and files. While you can deploy a webapp by the brute-force approach of dumping a WAR file or exploded WAR under the TOMCAT_HOME/webapps directory, that's just the simplest way. Tomcat supports a lot more than that.
Finally, it's critical to note that a web server is not a file server. You cannot use ordinary open/close/delete filesystem function calls to work directly with web applications, a webapp server is not a filesystem "share" point, not continously connected to the client and no matter how much the syntax of a URL may resemble a filesystem path, a URL is not a filesystem path. It is literally a Resource Locator and it's up to the web application to parse and decode the URL and determine what to return. A lot of the confusion comes from the fact that the Default Servlet will take any URLs not otherwise mapped in the WEB-INF/web.xml file, convert them to WAR-local resource paths, and copy the resources found at those locations to the HTTP response output stream. And, if the Default Servlet cannot find a resource at the assumed location, it will return a "404" response.
Customer surveys are for companies who didn't pay proper attention to begin with.