Mike, Thank you for the estimates. Priorities have shifted a bit, and I'm working on something else at the moment. I'll be in touch as soon as things clear up.
Look forward to diving into the Struts upload code, --Renaud > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > rg]On Behalf Of SCHACHTER,MICHAEL (HP-NewJersey,ex2) > Sent: Monday, February 04, 2002 8:36 AM > To: '[EMAIL PROTECTED]' > Subject: RE: Adapting the O'Reilly servlet classes for Struts upload > > > > >Our customer has decided this may be worth it 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
