>Our customer had decided this may be worth to him, so at this point I'm >exploring, trying to draw an estimate on how much time either option would >take (XP style, see below). Either fix the bugs in the existing Struts >upload module, or adapt O'Reilly's. How much time do you think it would take >you?
Here's estimates for the existing bugs: Bug #2017 Text entered in forms using multi-part/formdata cannot be utf8 ------------------------------------------------------------------------ To fix this, configuration parameters representing encoding need to be added to the config file and/or the character encoding needs to be detected in the request and passed to MultipartIterator. Special care needs to then be taken inside of MultipartIterator when handling text form elements. Maybe half a day's worth of work. Bug #5101 org.apache.struts.upload.MultipartIterator ---------------------------------------------------- This is probably a few lines of code. An hour tops. Bug #5274 OutOfMemoryError when uploading big files --------------------------------------------------- This is important to fix, bad coding on my part. I need to get rid of all the calls to (byte[] readLine()) in MultipartIterator and replace them them with (int readLine(byte[], int, int)). There used to be a problem with the latter method dropping bytes, it needs to be verified that that problem doesn't pop back up. I have a test case or two to verify that it doesn't pop up though, so it shouldn't be too bad. A few hours. Bug #2757 file upload problem: MultipartIterator: invalid multipart request data, doesn't start with boundary --------------------------------------------------------------------------- The basic idea is that when you try to do a forward after a multipart request, the content type doesn't change and it still thinks it's a multipart request. I haven't really looked into it; it may be deeper than that, so I won't try to estimate. Bug #3465 FormFile.destroy() doesn't work for temporary files ------------------------------------------------------------- As with my comment on the report, the problem lies in the java.io.File.delete() method, which seems to not work all the time on windows. I'm not too sure this is something that can be fixed. Bug #4170 MaxLengthExceeded doesn't stop file upload ---------------------------------------------------- I need to not use Exceptions for stuff like that, because it's a pretty crappy and non-working way to do things. A few hours should be all thats need to fix this, and will result in a different method to use to validate uploads. Bug #5822 byte lost every 4096 bytes after a 0A ----------------------------------------------- If this bug exists in 1.0.1 like it says, then I'm baffled. This might take a while to fix. >Talking architecture, I never understood how I could handle the >MaxLengthExceededException raised when someone attempts to upload a file >bigger than the maximum size. See >http://marc.theaimsgroup.com/?l=struts-user&m=100682691032695 >Is this something that sould be entered in the bug database, as feature >request maybe? >How can this be solved? This is bug #4170. This can be solved by not throwing exceptions when the max length is exceeded. Maybe a flag could be set somewhere either in MultipartIterator, the MultipartRequestHandler, or somewhere else that can accessed in the validate() method (or whatever's being used to validate these days..). Aside from not working, Exceptions have been said to suck up performance and are a bad way to do things, in my opinion. Although I'm not sure how much time I have, I'll be sure to make time to fix the critical stuff (2017, 5274, 4170, 5822), and to discuss fixes over email on the problems at hand. - mike -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
