File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes IDEs, Version Control and other tools and the fly likes issue with getting real path in servlet using eclipse Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "issue with getting real path in servlet using eclipse" Watch "issue with getting real path in servlet using eclipse" New topic

issue with getting real path in servlet using eclipse

Ramkumar Subburaj
Ranch Hand

Joined: Sep 07, 2007
Posts: 83

I am using eclipse europha 3.3.2 to build a web application.

project name is SampleWeb located in

i have a folder names test in

In servlet, i am using getSrevletContext().getRealPath("/test") to get the complete path of the folder. but i am getting the path like

instead of

Please help in solving this issue

SCJP 1.5, SCWCD 1.4.
Hanging between Web Services and EJB
Steve Luke

Joined: Jan 28, 2003
Posts: 4181

That isn't an error. Eclipse deploys the project to a working directory outside of the Project Workspace. It has to re-organize the files from the directory structure the Eclipse Workspace expects to the format a Web Application expects.

The path provided is the correct one being used when the application is running.

Jibitesh Prasad

Joined: Feb 20, 2007
Posts: 20
I think you should check this line again. I think this is not what you wrote in the code, specially the part.

Ramkumar Subburaj
Ranch Hand

Joined: Sep 07, 2007
Posts: 83
hey thanks for your reply.

now i got to know how it works. The projects runs from the wtpwebapps folder and not from the actual path.

but i have another problem.

in my application, the user uploads an image and i want to store in the local system where the server is running.

when i store the picture by getting the real path , it gets stored in the

wtpapps folder but it is not getting reflected in the actual folder
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17410

It's bad practice to try and store data in the webapp itself. You should treat the WAR as a read-only unit for a number of reasons.

One of these reasons is that the WAR may never be unpacked, or if you install the WAR in exploded (unpacked) format, the server might decide to pack it anyway. WAR files are not updateable via the standard Java API - you'd have to create a whole new WAR with the updated/added file(s), and that's just asking for trouble.

"Files" and "Directories" inside a ".war" file are not truly files and directories - they're just logical constructs. Just like in URLs, just because it looks like a file path and sometimes is a file path doesn't mean it's safe to always assume it will behave just like a file path.

Another reason to treat the WAR as read-only is that it's legal and often useful to share a single WAR between multiple servers. Having multiple concurrent writers also sets one up for problems.

Instead of writing files into the WAR, I recommend using an external directory that's accessible by your webapp server. You can make this directory location adjustable by setting it up as a resource definition in the web.xml file.

An IDE is no substitute for an Intelligent Developer.
Ramkumar Subburaj
Ranch Hand

Joined: Sep 07, 2007
Posts: 83
hey i do not want to write it inside war file.

My project is located in

But eclipse stores the images in

whatever you put in thee actual project folder gets updated in the above mentioned eclipse folder but the vice versa is no happening.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17410

Sorry. I lost track of that item when I went on my stock "don't store data in the WAR" rant #57.

However, you really are trying to access part of a WAR, because you're using the getServletContext() method, and that only works inside a webapp. And for the purposes of web application servers, a deployment unit is a WAR whether it's actually all bound together in a single .war file or still an open collection of files arranged in a directory tree that conforms to the WAR specification. Such a directory subtree is known as an "exploded WAR", since it's identical to what you'd get by unzipping a WAR file.

Exploded or archived, my recommendation is still the same. Your webapp server won't make the distinction. If you define a resource with the work directory's absolute path name in the WEB-INF/web.xml file, your app can do a JNDI lookup on the resource to get the path name instead of hard-coding the path in the application code.

For many appservers (including Tomcat), you can deploy with an override to this definition if you like, which is a big help when you want to be able to move the app from test to production without recompiling and rebuilding the app. I've done this many times - as far as I'm concerned, if you have to have 2 or more separate versions of a webapp for testing and production, you're not only doing something "theologically" wrong, you can't really test what runs in production. JNDI is your friend.

It's architecturally quite possible for a WAR to be stored as a BLOB in a database or downloaded from a remote server using custom classloaders, so the J2EE spec cannot assume that the WAR lives in an actual file directory and thus has a parent directory path. And returning to where I started - inside the execution environment of the webapp, you're in a WAR environment regardless of whether you zipped the app into an actual WAR file or not, so the same rules apply.

Which is why you're better off not trying to use it or places relative to it as filesystem paths.
I agree. Here's the link:
subject: issue with getting real path in servlet using eclipse
It's not a secret anymore!