This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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.
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.
Joined: Sep 07, 2007
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.
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.