aspose file tools*
The moose likes Tomcat and the fly likes deploy application in server Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Products » Tomcat
Bookmark "deploy application in server" Watch "deploy application in server" New topic
Author

deploy application in server

farag ahmed
Greenhorn

Joined: Dec 08, 2011
Posts: 12
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

Joined: Jun 25, 2001
Posts: 15665
    
  15

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.


Customer surveys are for companies who didn't pay proper attention to begin with.
farag ahmed
Greenhorn

Joined: Dec 08, 2011
Posts: 12
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: deploy application in server
 
Similar Threads
Log4J
How to deploy Servlet in Tomcat?
How to deploy war file in JBoss
Error: uncaught exception: [Exception... "Access to restricted URI denied" code: "1012" nsresult: "
Tomcat 6.0.30: cannot deploy application: access denied.