As Adeel says, it's relative path. Relative to the root of your context (application).
ServletContext.getRealPath(relativePath) attempts to find the location of the given resource on the server's file system.
I say 'attempts' because J2EE apps are not always run from directory structures on a file system. They can be deployed as packed war files. When getRealPath is used from within such an app, it will return null.
Originally posted by Ben Souther: ... I say 'attempts' because J2EE apps are not always run from directory structures on a file system. They can be deployed as packed war files. When getRealPath is used from within such an app, it will return null.
Ben,
So why is it so when the war file explodes to its folder structure and resources. In that case each resource has a physical path(canonical). So can you clarify why you can't get "a real path". If so then what you do acheive your task of finding "a real path".
unpackWARs Set to true if you want web applications that are placed in the appBase directory as web application archive (WAR) files to be unpacked into a corresponding disk directory structure, false to run such web applications directly from a WAR file. See Automatic Application Deployment for more information.
A simple rule of thumb is not to rely on getRealPath if you want your app to be portable.
We're pleased to have you here with us on the Ranch, but there are a few rules that need to be followed, and one is that proper names are required. Please take a look at the JavaRanch Naming Policy and adjust your display name to match it.
In particular, your display name must be a first and a last name separated by a space character, and must not be obviously fictitious.