struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Renaud Waldura" <renaud.wald...@ZeroG.Com>
Subject RE: Adapting the O'Reilly servlet classes for Struts upload
Date Tue, 05 Feb 2002 21:13:56 GMT

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

Look forward to diving into the Struts upload code,


> -----Original Message-----
> From:
> [
> rg]On Behalf Of SCHACHTER,MICHAEL (HP-NewJersey,ex2)
> Sent: Monday, February 04, 2002 8:36 AM
> To: ''
> 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
> 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
> >
> >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:
For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message