• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Working with tomcat

 
Naveen Madarapu
Ranch Hand
Posts: 64
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


I have installed tomcat and have successfully deployed a J2EE project. But the next day when i tried to access the project folder I got a HTTP 404 error stating that the resource is not available.

what's wrong? One day I am able to access the project, and the next it says resource unavailable
 
Pondurai Singh
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Are you getting any error in tomcat console log?
Check is your tomcat server started properly?
Once again deploy your project to server, start the server.
 
Tim Holloway
Saloon Keeper
Posts: 18304
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic