> is exactly what i want. However, i cannot access the
> getRealPath method
> ("non-static method cannot be accessed from static
> context"). i think this
> is b/c my program is not a servlet (does not extend
> any servlet
> interface/class).
That wasn't "real" code, getRealPath isn't a static method.
As someone else mentioned, you need to get access to the ServletContext somehow (every framework I know of provides access to this, though some may be more buried than others).
But the getRealPath will work, and is portable across containers. One problem with this is that if you normally deploy you application from a WAR file, then any time you redeploy the WAR file, any files you have created within your web app are destroyed by the redeployment. You can get around this by deploying an exploded WAR file in a directory structure that you maintain
There is another option, but it is Glassfish specific. GF allows you to specify "alternate doc roots" in the sun-web.xml file. These give you the ability to map arbitrary locations within in your file system to be within your web apps context.
The specific advantage of this is for the case where you may have, say, a lot of static data that needs to survive redeploys. The benefit is that you get to specify in your deployment exactly where this data lives on your file system, and where it exists within your web app hierarchy. The downside is that this is not portable to other containers.
I like to use alternate doc roots because a lot of our data is static, and it's big, and it has little to do with the rapidly changing parts of the application. I can easily back up or replace my small WAR files without hurting the vast amount of static data, makes deployments "less scary" and easier to roll back.
Note, getRealPath returns the proper path for all of these resources. Resources mapped in via the alternate doc root mechanism work fine with getRealPath.
> let me step back and describe again my goal. what
> i'm trying to do is:
> when someone clicks a link, i will generate a file
> from DB and then return
> that file to the user/browser. the way i was
> thinking of doing that was
> having the link's event handler first create the
> file, and then navigate to
> another page. that page would be the generated file
> or would re-direct to
> the generated file.
getRealPath is your solution. Your challenge is providing access to the routine to your code.
> my problem with the above is that the file i generate
> needs to be put in the
> docroot. but, i may not know in advance the absolute
> path of the docroot (so
> i don't know how to put the file there). a solution
> i'm considering for
> this is using a properties file to store the docroot
> path. is there a
> better way?
If you can avoid the property file, your application remains nimble (for example the app will run unchanged on your Windows dev box and on the Unix production box). And the property is one less thing to manage and coordinate and debug. To me, it would be VASTLY better to use getRealPath than to hard code a path in some configuration file if at all possible.
(Yes, alternate doc roots "violates" that meme...yes, it's a pain to have to maintain in two places, but it's easier than juggling several 100MBs of files around for a deploy.)
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=244645