At 03:15 PM 2/1/02, Renaud Waldura wrote: <... snip ...>
> > It would definately be worth your time, if you're willing to work on it, > > to address these bugs. I'll be a bit more vigilant about email and > >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? Just as a point of reference, some time ago I wrote an adaptor from Resin's built-in multipart mechanism to the MultipartRequestHandler interface. It only took me a few hours. I'm not familiar with the O'Reilly implementation, but I'd be surprised if it took much longer to write an adaptor for that. Of course, I'd rather see the bugs in the Struts implementation fixed! ;-) -- Martin Cooper > > into detail. The overall architecture of file upload is not > > too bad in my opinion, and doesn't need changing. Just the > > implementation. I bet there might be some performance issues > >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? > > > > So, how about we do this "extreme programming" style > >My company works in full XP mode already. I think it's a great idea. > > >Thank you for being so responsive, > >--Renaud > > >-- >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]>
