Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

deploy application in server

 
farag ahmed
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I have a web application which is working perfect in local machine. I want to put this application in server where we have running tomcat there. I changed all paths in the properties file to match the new location in the server.

After placing my application in server, the main menu working fine but I had problem with paths (error message: the path is not exist although it is exist in the server).

Does creating war file and deploy it using tomcat manager make all paths recognizable?


Thanks
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18152
52
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are 3 kinds of "paths".

1. The "path" in a URL. This one confuses people, because it's actually NOT a filesystem path - it just looks like one. And, in some cases, can be translated into one, depending on what application receives the URL. Unfortunately, that includes the default servlet, which is good, because that's how Tomcat locates JavaScript files, images, CSS and other non-J2EE stuff. But it's bad because people think that it applies to other things as well. A URL is really just a character string that gets parsed, sent to a pattern matcher where it's compared against patterns in web.xml, and then routed to a servlet/JSP.

2. Resource paths. Resource paths are relative to the root of a deployed WAR. For example, "/WEB-INF/classes/com/javaranch/Saloon.class" or "/images/moose.jpg". Oficially, a WAR is always in JAR (ZIP) format, so once again, this isn't, strictly speaking, a filesystem path, it's a directory path within the ZIP file. However, Tomcat also supports "exploded" (unzipped) WARs, in which case the directories and files in the WAR really are directories and files. However, Tomcat resolves resource paths the same way, regardless of whether the WAR was exploded or not. The default servlet uses a resource path extracted from the incoming URL. Note that the correct syntax for a webapp resource path is in absolute form (begins with "/"), although for resources, "/" means the root of the WAR, not the root of the server's filesystem.

3. Filesystem paths. Tomcat, like almost all other webapp servers, cannot directly serve up filesystem-path objects. Tomcat is a WEB server, not a FILE server. Plus, putting all or part of the server filesystem out on the open Internet where just anybody could access it would be a grave security risk. However, J2EE webapps can be configured to take a URL and convert it to a (absolute) filesystem path, then do something with what it finds there. For example, I could create a servlet called "CopyImageServlet", tell it that /var/lib/mywebapp/images" holds the image files and use it as an image upload/download directory, with the CopyImageServlet doing the work of copying data to/from that directory. Note:Never upload anything into a WAR. Always upload into a directory that's external to both Tomcat and the deployed webapps!

The absolute filesystem paths for WAR resources depends on how the appserver was configured. That is why it's better to use resource paths to resolve resources that are part of the deployed WAR itself, and externally-defined absolute filesystem paths for resources that are not part of the deployed WAR. Relative filesystem paths should be avoided.
 
farag ahmed
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:There are 3 kinds of "paths".

1. The "path" in a URL. This one confuses people, because it's actually NOT a filesystem path - it just looks like one. And, in some cases, can be translated into one, depending on what application receives the URL. Unfortunately, that includes the default servlet, which is good, because that's how Tomcat locates JavaScript files, images, CSS and other non-J2EE stuff. But it's bad because people think that it applies to other things as well. A URL is really just a character string that gets parsed, sent to a pattern matcher where it's compared against patterns in web.xml, and then routed to a servlet/JSP.

2. Resource paths. Resource paths are relative to the root of a deployed WAR. For example, "/WEB-INF/classes/com/javaranch/Saloon.class" or "/images/moose.jpg". Oficially, a WAR is always in JAR (ZIP) format, so once again, this isn't, strictly speaking, a filesystem path, it's a directory path within the ZIP file. However, Tomcat also supports "exploded" (unzipped) WARs, in which case the directories and files in the WAR really are directories and files. However, Tomcat resolves resource paths the same way, regardless of whether the WAR was exploded or not. The default servlet uses a resource path extracted from the incoming URL. Note that the correct syntax for a webapp resource path is in absolute form (begins with "/"), although for resources, "/" means the root of the WAR, not the root of the server's filesystem.

3. Filesystem paths. Tomcat, like almost all other webapp servers, cannot directly serve up filesystem-path objects. Tomcat is a WEB server, not a FILE server. Plus, putting all or part of the server filesystem out on the open Internet where just anybody could access it would be a grave security risk. However, J2EE webapps can be configured to take a URL and convert it to a (absolute) filesystem path, then do something with what it finds there. For example, I could create a servlet called "CopyImageServlet", tell it that /var/lib/mywebapp/images" holds the image files and use it as an image upload/download directory, with the CopyImageServlet doing the work of copying data to/from that directory. Note:Never upload anything into a WAR. Always upload into a directory that's external to both Tomcat and the deployed webapps!

The absolute filesystem paths for WAR resources depends on how the appserver was configured. That is why it's better to use resource paths to resolve resources that are part of the deployed WAR itself, and externally-defined absolute filesystem paths for resources that are not part of the deployed WAR. Relative filesystem paths should be avoided.


Thanks alot, this is exactly what solve my problem. Sorry that I had no time to write this.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic