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] ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
