100% agreed. All the more reason why (1) isn't the best option in the
general case. For Tomcat and exploded deployments, it'll work. As I said,
the most flexible, portable option is (2).
Thanks to Yoav for keeping the interop flag flying high and mighty. ;)
justin
At 12:33 PM 10/17/2003, you wrote:
>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)
____________________________________
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)
