On Thu, Mar 10, 2011 at 5:02 PM, Josh Canfield <joshcanfi...@gmail.com> wrote: >> Sorry, but that's a really bad advice - never put uploaded files under >> the context path of your application. What happens when you update the >> WAR? > Strongly agree. >> return new >> BufferedImageStreamResponse(ImageIO.read(imageStorage.getImageInputStream(imageId))); > What is the value in using ImageIO instead of just streaming the file bits?
Yeah, that's a bad generic example - in the case I copied it from it's used to encode various source formats and sizes to a common output format. But consider whether you want to do it on the fly and pay recurring costs. Kalle > On Thu, Mar 10, 2011 at 4:33 PM, Kalle Korhonen > <kalle.o.korho...@gmail.com> wrote: >> On Thu, Mar 10, 2011 at 4:11 PM, Thiago H. de Paula Figueiredo >> <thiag...@gmail.com> wrote: >>> On Thu, 10 Mar 2011 19:24:52 -0300, Rich M <rich...@moremagic.com> wrote: >>>> Primarily because I can't think of a reasonable way to build a URL to the >>> I think you have a confusion here. The folder structure you use while >>> developer doesn't matter, the one in the WAR, exploded or not, does. Servlet >>> containers normally exploded (unzip) your WAR into a folder. Anything inside >>> that folder is available. Example: if you have a image.jpg file inside the >>> root folder of the root context, it's URL is at http://domain/image.jpg >>> directly. Better yet, most servlet containers (at least Tomcat and Jetty) >>> support WARs: you don't even create a WAR file, just put the contents of it >>> inside some configured folder. >> >> Sorry, but that's a really bad advice - never put uploaded files under >> the context path of your application. What happens when you update the >> WAR? >> >> To do it right, you have basically two options, either a) map a >> virtual path to a physical folder, e.g. /images/ to /var/www/images/ >> or b) open a stream to stream the files from the physical folder. If >> a) and you are not using anything in front of your servlet container, >> you'd create another "images" web application (with tomcat, that's a >> single context file) and for b) it'll perform just as well as the >> first option if it's the same container serving the bits and you use >> StreamResponse regardless of whether the bytes come from database or >> file - it's simple to do, e.g: >> public StreamResponse onUploadedImage() throws FileNotFoundException, >> IOException { >> return new >> BufferedImageStreamResponse(ImageIO.read(imageStorage.getImageInputStream(imageId))); >> } >> >> Kalle >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
