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
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: struts-dev-return-6555-renaud.waldura=zerog.com@jakarta.apache.org
> [mailto:struts-dev-return-6555-renaud.waldura=zerog.com@jakarta.apache.o
> rg]On Behalf Of SCHACHTER,MICHAEL (HP-NewJersey,ex2)
> Sent: Monday, February 04, 2002 8:36 AM
> To: 'struts-dev@jakarta.apache.org'
> 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:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message