Richard, Thank you so much! I will do that.
Roland On 5/22/02 12:09 AM, "Richard Yee" <[EMAIL PROTECTED]> wrote: > Roland, > Search the Servlet-Interest archives for messages having the subject of: > Sevlet Upload Question > and > Re: Sevlet Upload Question > > There was a discussion about changing Jason Hunter's file upload code so > that it generated a unique filename for the upload file or it stored the > file in memory rather than writing it to disk in order to write the file > into a DB. > You might want to contact Jeff Schnitzer, the originator of the thread, to > see what he ended up with. > > Regards, > > Richard > > > At 10Delivered-To: [EMAIL PROTECTED] > X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) > X-Accept-Language: en > Date: Wed, 1 May 2002 00:09:59 -0700 > Reply-To: "A mailing list for discussion about Sun Microsystem's Java > Servlet API Technology." <[EMAIL PROTECTED]> > Sender: "A mailing list for discussion about Sun Microsystem's Java Servlet > API Technology." <[EMAIL PROTECTED]> > From: Jason Hunter <[EMAIL PROTECTED]> > Subject: Re: Sevlet Upload Question > To: [EMAIL PROTECTED] > > OK, you've convinced me. I'm working on a version of the COS library > that will support pluggable file renaming/moving logic. > -jh- > Jeff Schnitzer wrote: >> >> Hey, cool, thanks for chiming in :-) >> >>> From: Jason Hunter [mailto:[EMAIL PROTECTED]] >>> >>> Is it really a deficiency in the com.oreilly.servlet code? >> >> I think my use case is probably pretty typical: A website that allows >> people to upload images and share them with others. Because of the way >> digital cameras automatically name images, the probability that two >> people will simultaneously upload two different files with the same name >> is high. >> >> Thus my uploaders need to work in isolated environments; filenames need >> to be pretty much irrelevant. >> >>> If you want some other front end, >>> providing things like overwrite handling or saving different files to >>> another location, you can write another front end basing on the MR >>> code. I see that's what you did; you wrote a front end to read the >>> files into memory and avoid the filesystem. >> >> Yup :-) It would have been nicer if I could have extended the >> MultipartWrapper/MultipartRequest to override the behavior I needed, >> though. >> >>> But to be honest, I'm going to need to be convinced it's necessary. >>> I've let MR write the files to a temp directory and then let the web >> app >>> move them to the appropriate "golden" location. The web app can >> enforce >>> the business logic on how it want to deal with conflicts (like newer >>> file wins or original file wins or file gets renamed or whatever). >> That >>> also saves you from ever having partial uploads in the "golden" >>> location. A file move on the same filesystem is an extremely fast >>> operation compared to the upload, so no slowdown. It also solves the >>> problem where you need to change the location based on a parameter, >>> since there's no guarantee the parameter will come before the files in >>> the upload stream. >> >> The problem is not for collisions after uploads, but during the upload >> process. Ideally, each file would be written to a unique temporary >> filename until the upload is complete. >> >> I was lazy, and I could get away with it, so I just persisted my uploads >> in memory. Temporary files would be better. >> >> BTW, thanks for the code (and the book)! >> >> Jeff Schnitzer >> [EMAIL PROTECTED] >> > :15 AM 5/21/2002 -0500, you wrote: >> Hi, >> >> I am writing a jsp program in which user can send email attachment. Since >> users are not allowed to upload file from their local machine to the server. >> Is there a way to write a jsp program which can send out the email >> attachment WITHOUT first uploading the file to the sever? It is urgent , >> please help. >> >> Roland >> >> =========================================================================== >> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff >> JSP-INTEREST". >> For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST >> DIGEST". >> Some relevant FAQs on JSP/Servlets can be found at: >> >> http://archives.java.sun.com/jsp-interest.html >> http://java.sun.com/products/jsp/faq.html >> http://www.esperanto.org.nz/jsp/jspfaq.jsp >> http://www.jguru.com/faq/index.jsp >> http://www.jspinsider.com > > =========================================================================== > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff > JSP-INTEREST". > For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". > Some relevant FAQs on JSP/Servlets can be found at: > > http://archives.java.sun.com/jsp-interest.html > http://java.sun.com/products/jsp/faq.html > http://www.esperanto.org.nz/jsp/jspfaq.jsp > http://www.jguru.com/faq/index.jsp > http://www.jspinsider.com =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
