Howdy,
;(

>(1) Write the file and directly reference it. For example, if you
write
>your file into $TOMCAT/webapps/appname/myfile.html, then you can point
your
>browser directly to it and it can download. If you always deploy your
app
>exploded (not as a .war), then this is fine because you can use java's
>java.io.* classes to directly write to your filesystem. This method
limits
>your deployment options. There's some way to construct the filesystem
path
>to your webapp root through the javax.servlet.* classes, but I forgot
what
>it is -- instead, pass the value in as an init parameter (jndi, servet
init
>param, outside config file -- take your pick) to your servlet. It
would be
>something like:
>
>// In your servlet
>String webAppRoot = MyConfig.getWebAppRootPath();
>File file = new File(webAppRoot+"/myfile.html");
>// Write whatever data you want to the File

This is a common misconception. It's a wrong approach. The container
is not required to give you write access under your webapp area, and
many containers/server administrators don't for security reasons. The
only portable space for you to write is the value (a File) of
javax.servlet.context.tempdir context attribute.

There is not way to construct the filesystem path to your webapp root
through the javax.servlet.* classes, that's plain wrong. There is
intentionally no such way, for two reasons:
- Servlet containers are not required to be on a filesystem. There
Oracle database containers and portable device containers that don't
have a normal filesystem under them.

- Webapps are supposed to be self-contained within their WAR file.
Containers aren't even required to support exploded WAR deployment.
Local filesystem access via the java.io.* classes is usually indicative
of a bad webapp design. Use a URL/Resource-based approach instead.

The last part of your message: having a configurable init parameter or
JNDI env-entry to designate the writing location, is good. This lets
the server administrator, rather than the app developer, decide what a
good location is. This is proper role separation.

Yoav Shapira



>
>(2) Write the file (anywhere), then make it available to users through
a
>Servlet which serves the content. Instead of writing a physical file
to
>your webapp file tree, create a servlet that takes an argument
specifying
>which file the user desires. An example URL would look like:
>
>http://server.com/myApp/NewFileServlet?path=reports.cash.mostRecent
>
>This Servlet would take into account session info, the path parameter,
>security considerations, etc, to find the correct file and serve it
back to
>the user. This gives you the choice to store the file anywhere --
>database, xml, remote server, anywhere -- and then serve it back up
when
>requested.
>
>You also avoid any deployment problems because you're not relying on
the
>underlying filesystem to support your application's new files.
>
>
>Hope that sheds some light on the topic ... (1) is quicker and easier,
(2)
>is more robust and flexible, but is more involved to implement. Take
your
>pick based on whatever other requirements you have. If you have more
>questions, don't hesitate to ask.
>
>justin
>
>
>>Thanks
>>Jason
>>
>>Justin Ruthenbeck wrote:
>>
>>>
>>>Yes, it is possible. Give us an idea of your deployment setup (are
you
>>>deploying as a .war file? Using default root paths? Anything
special?)
>>>and we can suggest the best way to go about doing it.
>>>
>>>justin
>>>
>>>At 04:16 PM 10/16/2003, you wrote:
>>>
>>>>Is it possible, in a servlet, to write to a temporary file in a
location
>>>>that I would then be able to link to so the users can download? I
>>>>couldn't find any information indicating either way.
>>>>
>>>>Thanks
>>>>Jason
>>>>
>>>>
>>>>
>>>>--------------------------------------------------------------------
-
>>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>>>>For additional commands, e-mail: tomcat-user-help@(protected)
>>>
>>>____________________________________
>>>Justin Ruthenbeck
>>>Software Engineer, NextEngine Inc.
>>>justinr - AT - nextengine DOT com
>>>Confidential
>>>   See http://www.nextengine.com/confidentiality.php
>>>____________________________________
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>>>For additional commands, e-mail: tomcat-user-help@(protected)
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>>For additional commands, e-mail: tomcat-user-help@(protected)
>
>
>____________________________________
>Justin Ruthenbeck
>Software Engineer, NextEngine Inc.
>justinr - AT - nextengine DOT com
>Confidential
>   See http://www.nextengine.com/confidentiality.php
>____________________________________
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>For additional commands, e-mail: tomcat-user-help@(protected)




This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
For additional commands, e-mail: tomcat-user-help@(protected)