RE: Adapting the O'Reilly servlet classes for Struts upload
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-userm=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]
RE: Adapting the O'Reilly servlet classes for Struts upload
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-userm=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]
Re: Adapting the O'Reilly servlet classes for Struts upload
I found a post to struts-dev where Mike wishes he had the time to replace the existing upload code with O'Reilly's implementation -- or at least this is my understanding, correct me if I'm wrong. Is this a recent post? (Can you send the URL?) I'm also interested in the upload bug fixing. I heard it is suffice to download the mod_webapp and recompile it. I'd like to know if there is a Linux 7.2 compiled version of it. Thanks Ivan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Adapting the O'Reilly servlet classes for Struts upload
Renaud, My company is using Struts pretty extensively, the upload module in particular, and we've come across some pretty serious bugs that have prompted an internal discussion about its deficiencies. ;) I found a post to struts-dev where Mike wishes he had the time to replace the existing upload code with O'Reilly's implementation -- or at least this is my understanding, correct me if I'm wrong. Hmm. I think I was trying to make an implementation of struts upload that used the O'Rielly upload package. Replacing the existing upload code isn't really necessary, but fixing some bugs in the existing package is. As my company has a business interest in getting the upload module working perfectly, they may be willing to do the work and donate it to the Struts project. But first I'd like to hear from you what the current status of the Struts upload is like; is it in your opinion stable and production quality? Is integrating the O'Reilly upload stuff in Struts a good idea? A quick link to the list of bugs for File Upload: http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSI GNEDbug_status=REOPENEDemail1=emailtype1=substringemailassigned_to1=1em ail2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=change din=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutscomponen t=File+Uploadshort_desc=short_desc_type=allwordssubstrlong_desc=long_des c_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeyword s=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype =doitorder=%27Importance%27 There are 10 outstanding issues for file upload in Struts, some minor, some not so minor. I'm almost at the point where I can devote some time to addressing these issues, and maybe even do a partial re-write of the MultipartIterator class if necessary. 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 help out as much as I can. To start you really want to look at the DiskMultipartRequestHandler and MultipartIterator class, thats where all the trouble starts. There's a few ways it could be improved, and in further emails I'd be happy about going 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 too, which I think I'm much more capable of handling now than when I first wrote it. So, how about we do this extreme programming style, where we figure out what needs to be done to get stuff running as optimally as possible through email, break up the things into small tasks, and take on the tasks one by one. I'd be more than happy to make the struts upload work as well as possible, it's been bothering me for a while and I haven't had time. Thank you for your answers, --Renaud Thank you for helping, Mike -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Adapting the O'Reilly servlet classes for Struts upload
Hi Mike, Hmm. I think I was trying to make an implementation of struts upload that used the O'Reilly upload package. Replacing the existing upload code isn't really necessary, but fixing some bugs in the existing package is. I see. 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? 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-userm=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]
Re: Adapting the O'Reilly servlet classes for Struts upload
At 2:46 PM -0800 1/31/02, Renaud Waldura wrote: But first I'd like to hear from you what the current status of the Struts upload is like; is it in your opinion stable and production quality? Is integrating the O'Reilly upload stuff in Struts a good idea? I just implemented something for the first time with the Struts upload code in about 20 minutes last week. It works like a charm. On the other hand, in the past I've used the com.oreilly.servlets Multipart Request classes, but never been very satisfied with the API. I found a post to struts-dev where Mike wishes he had the time to replace the existing upload code with O'Reilly's implementation -- or at least this is my understanding, correct me if I'm wrong. Is this a recent post? (Can you send the URL?) Joe -- Joe Germuska Lead Programmer JGSullivan Interactive, Inc. [EMAIL PROTECTED] 312/943-1600 x2488 (v) 312/943-9675 (f) [EMAIL PROTECTED] 312/907-7893 (m)7183 (nextel private) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
