Re: commons-fileupload
There are about 1000 examples of this using PHP. Not knowing PHP, I would assume that the logic is the same, so that might be a good place to start. On 8/2/06, Henri Yandell [EMAIL PROTECTED] wrote: On 7/23/06, Jürgen Hoffmann [EMAIL PROTECTED] wrote: Hi all, I am trying to implement commons-fileiupload inside my application. My Application uses the Turbine Framework, which provides a convenient wrapper around commons-fileupload. Now to my case. I want to display the user a file upload statistics screen using AJAX. Which means I need to access the sp far temporarily stored bytes within parseRequest(..). Is it possible to retrieve: 1. the Total Bytes of the complete File 2. How much of the file has been uploaded so far Hi Jürgen, I'm not a FileUpload expert, but I think being able to support progress bars is one of the things planned in FileUpload 2.0. SO the answer here would be that the above isn't possible with the current API. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons fileupload
Well, I set my 'setSizeThreshold()' to a fairly large number (2^24 or 16,777,216 or 16MB, far larger than the size of my file), but it is still doubling in size when uploaded. Again, strangely, I'm getting two files written, one automatically (which I thought would be gone now?) and one manually. The one written automatically (upload_002.xml) is correct (about 1MB); a copy of the file I uploaded. Another file, which was created with this line: item.write(File.createTempFile(portaltest-, null)); Comes back as twice the size, about 2MB, as portaltest-63344.tmp. I can/will hook up a tcp monitor, but the problem with that is, I'm sending up a lot of data, at least 1MB of XML. Whenever I do small files, say ~100KB, it works fine. So, here are my questions: 1) If I'm setting the 'setSizeThreshold()' large enough, why is it *still* writing out a temp file to disk? Is this normal? 2) The documentation for 'getSizeThreshold()' says: Returns the size threshold beyond which files are written directly to disk. The default value is 1024 bytes. But when I do a 'getSizeThreshold()' I get 10240. Is the documentation simply stale? 3) What happens between when the uploaded file is temporarily written to disk, and when the 'parseRequest()' is called? Between these two events is when the size problems seem to manifest. Thanks- Robert Martin Cooper wrote: On 6/18/06, Robert J. Carr [EMAIL PROTECTED] wrote: Mike/Martin- I will hook up a monitor (I'm familiar with tcpmon) but as I explained, it seems to be beyond that point, as the file is written to disk correctly when done automatically, but then written incorrectly when done manually (or when referred to). What's strange, though, is that nobody else has reported this kind of problem, and the difference between the servlet and portlet code is miniscule. The size of a file item is determined from the content itself by the same code for both cases. I've read about a file-writing size threshold, and perhaps this is configurable? Yes, it is. You can call the setSizeThreshold method on the file item factory. See the user guide for an example. -- Martin Cooper As I also explained, the problem only seems to happen with large files, when they are written to disk and pass this threshold. Not an ideal fix, but if I just move this threshold up considerably higher, I'm guessing it would work, and would at least allow me to see something different. I'll try that, and attach the moitor, and report my results. Thanks for the time. Robert On Sat, 17 Jun 2006, Mike Sparr - www.goomzee.com wrote: Martin, http://ethereal.com/ (very easy to use and when you run it, you can choose which network adapter to capture traffic. After you capture, then you can run the viewer to analyze). In addition, I believe AXIS includes a network monitoring tool built into the library so you may want to use that. Perhaps you could tweak it to Monitor other traffic, but again SOAP is http... org.apache.axis.monitor.SOAPMonitorService Hope that helps, Mike On 6/17/06 4:14 PM, Martin Cooper [EMAIL PROTECTED] wrote: On 6/15/06, Robert J. Carr [EMAIL PROTECTED] wrote: I am attempting to use the fileupload package and having strange results. I have a file type form element that I am uploading an xml file through to. The xml file I'm uploading is about 1.1MB . However, when I print some of the metadata about the uploaded FileItem, here's what I get: Do you have any way of capturing what's on the wire, so that we could look at the contents of the incoming request? Maybe Windows Network Monitor or Ethereal or something? Without that, it will be hard to figure out what's going on. -- Martin Cooper content-type: text/xml size: 2363688 (via getSize()) length: 2363688 (via get().length) When I look in my tomcat temp directory, I see a file: upload_00014.xml Which is the correct file, it is 1.1MB and passes diff. However, when I attempt to write the file to disk: item.write(File.createTempFile(portaltest-, null)); I get a file written: portaltest-64578.tmp Which is incorrect, and a size of 2.3 MB (which matches the size above). I'm using the latest 1.1.1 release (but same thing happens with 1.1). To get my fileitems, I make this sequence of calls: FileItemFactory factory = new DiskFileItemFactory(); PortletFileUpload upload = new PortletFileUpload(factory); ListFileItem items = (ListFileItem) upload.parseRequest(request); To add another twist, this seems to work fine for smaller files (less than about 50KB in size). I'm also getting an exception thrown later, and not entirely sure where it is coming from. It may be a red herring, but I'll include it for completeness: java.io.FileNotFoundException: /opt/java/LiferayPro3.6.1/temp/upload__41c20f98_10bd8eb6a9d__7ffe_0002.tm p (No such file or directory) So I
Re: commons fileupload
On 6/19/06, Robert J. Carr [EMAIL PROTECTED] wrote: Well, I set my 'setSizeThreshold()' to a fairly large number (2^24 or 16,777,216 or 16MB, far larger than the size of my file), but it is still doubling in size when uploaded. Again, strangely, I'm getting two files written, one automatically (which I thought would be gone now?) and one manually. The one written automatically (upload_002.xml) is correct (about 1MB); a copy of the file I uploaded. Are you sure that's the name of the file being written? It doesn't match the pattern for temp files created by FileUpload, so I'm not sure where that would be coming from. Another file, which was created with this line: item.write(File.createTempFile(portaltest-, null)); Comes back as twice the size, about 2MB, as portaltest-63344.tmp. I can/will hook up a tcp monitor, but the problem with that is, I'm sending up a lot of data, at least 1MB of XML. Whenever I do small files, say ~100KB, it works fine. So, here are my questions: 1) If I'm setting the 'setSizeThreshold()' large enough, why is it *still* writing out a temp file to disk? Is this normal? Nope. Are you sure you're setting the threshold on the factory before calling parseRequest? 2) The documentation for 'getSizeThreshold()' says: Returns the size threshold beyond which files are written directly to disk. The default value is 1024 bytes. But when I do a 'getSizeThreshold()' I get 10240. Is the documentation simply stale? That's a Javadoc error that I've now fixed. Thanks for pointing it out. 3) What happens between when the uploaded file is temporarily written to disk, and when the 'parseRequest()' is called? Between these two events is when the size problems seem to manifest. It's the parseRequest call that writes temp files to disk when necessary. Pretty much nothing interesting happens outside of the parseRequest call. -- Martin Cooper Thanks- Robert Martin Cooper wrote: On 6/18/06, Robert J. Carr [EMAIL PROTECTED] wrote: Mike/Martin- I will hook up a monitor (I'm familiar with tcpmon) but as I explained, it seems to be beyond that point, as the file is written to disk correctly when done automatically, but then written incorrectly when done manually (or when referred to). What's strange, though, is that nobody else has reported this kind of problem, and the difference between the servlet and portlet code is miniscule. The size of a file item is determined from the content itself by the same code for both cases. I've read about a file-writing size threshold, and perhaps this is configurable? Yes, it is. You can call the setSizeThreshold method on the file item factory. See the user guide for an example. -- Martin Cooper As I also explained, the problem only seems to happen with large files, when they are written to disk and pass this threshold. Not an ideal fix, but if I just move this threshold up considerably higher, I'm guessing it would work, and would at least allow me to see something different. I'll try that, and attach the moitor, and report my results. Thanks for the time. Robert On Sat, 17 Jun 2006, Mike Sparr - www.goomzee.com wrote: Martin, http://ethereal.com/ (very easy to use and when you run it, you can choose which network adapter to capture traffic. After you capture, then you can run the viewer to analyze). In addition, I believe AXIS includes a network monitoring tool built into the library so you may want to use that. Perhaps you could tweak it to Monitor other traffic, but again SOAP is http... org.apache.axis.monitor.SOAPMonitorService Hope that helps, Mike On 6/17/06 4:14 PM, Martin Cooper [EMAIL PROTECTED] wrote: On 6/15/06, Robert J. Carr [EMAIL PROTECTED] wrote: I am attempting to use the fileupload package and having strange results. I have a file type form element that I am uploading an xml file through to. The xml file I'm uploading is about 1.1MB . However, when I print some of the metadata about the uploaded FileItem, here's what I get: Do you have any way of capturing what's on the wire, so that we could look at the contents of the incoming request? Maybe Windows Network Monitor or Ethereal or something? Without that, it will be hard to figure out what's going on. -- Martin Cooper content-type: text/xml size: 2363688 (via getSize()) length: 2363688 (via get().length) When I look in my tomcat temp directory, I see a file: upload_00014.xml Which is the correct file, it is 1.1MB and passes diff. However, when I attempt to write the file to disk: item.write(File.createTempFile(portaltest-, null)); I get a file written: portaltest-64578.tmp Which is incorrect, and a size of 2.3 MB (which matches the size above). I'm using the latest 1.1.1 release (but same thing happens with 1.1). To get my fileitems, I
Re: commons fileupload
Thanks for the quick response. The one written automatically (upload_002.xml) is correct (about 1MB); a copy of the file I uploaded. Are you sure that's the name of the file being written? It doesn't match the pattern for temp files created by FileUpload, so I'm not sure where that would be coming from. Wow, that's really strange. I'm sure that is the filename (just double checked) and I'm sure I'm not writing it (just double checked it) and I'm sure it is being written during the upload process (again, just double checked). I have the relatively recent 1.1.1 version of the software. I don't know what to say ... could it have something to do with the portal / portlet layer? It is possible there is already code in there that automatically parses the request and writes the file if it determines a file upload? I'll look into this now ... for reference, I'm using Liferay Pro 3.6.1. 1) If I'm setting the 'setSizeThreshold()' large enough, why is it *still* writing out a temp file to disk? Is this normal? Nope. Are you sure you're setting the threshold on the factory before calling parseRequest? Yep, I'm sure ... but now I'm convinced it is the portal that is doing strange things. That's a Javadoc error that I've now fixed. Thanks for pointing it out. Cool. It's the parseRequest call that writes temp files to disk when necessary. Pretty much nothing interesting happens outside of the parseRequest call. Okay, thanks again ... I'll look into portal issues now, thanks again for the quick response. Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons fileupload
On 6/19/06, Robert J. Carr [EMAIL PROTECTED] wrote: Thanks for the quick response. You can attribute that to me being in a brief break between employers right now. ;-) The one written automatically (upload_002.xml) is correct (about 1MB); a copy of the file I uploaded. Are you sure that's the name of the file being written? It doesn't match the pattern for temp files created by FileUpload, so I'm not sure where that would be coming from. Wow, that's really strange. I'm sure that is the filename (just double checked) and I'm sure I'm not writing it (just double checked it) and I'm sure it is being written during the upload process (again, just double checked). I have the relatively recent 1.1.1 version of the software. I don't know what to say ... could it have something to do with the portal / portlet layer? It is possible there is already code in there that automatically parses the request and writes the file if it determines a file upload? I'll look into this now ... for reference, I'm using Liferay Pro 3.6.1. A quick Google shows that Liferay does in fact incorporate Commons FileUpload, so this is very likely the source of the problems. -- Martin Cooper 1) If I'm setting the 'setSizeThreshold()' large enough, why is it *still* writing out a temp file to disk? Is this normal? Nope. Are you sure you're setting the threshold on the factory before calling parseRequest? Yep, I'm sure ... but now I'm convinced it is the portal that is doing strange things. That's a Javadoc error that I've now fixed. Thanks for pointing it out. Cool. It's the parseRequest call that writes temp files to disk when necessary. Pretty much nothing interesting happens outside of the parseRequest call. Okay, thanks again ... I'll look into portal issues now, thanks again for the quick response. Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons fileupload
On 6/18/06, Robert J. Carr [EMAIL PROTECTED] wrote: Mike/Martin- I will hook up a monitor (I'm familiar with tcpmon) but as I explained, it seems to be beyond that point, as the file is written to disk correctly when done automatically, but then written incorrectly when done manually (or when referred to). What's strange, though, is that nobody else has reported this kind of problem, and the difference between the servlet and portlet code is miniscule. The size of a file item is determined from the content itself by the same code for both cases. I've read about a file-writing size threshold, and perhaps this is configurable? Yes, it is. You can call the setSizeThreshold method on the file item factory. See the user guide for an example. -- Martin Cooper As I also explained, the problem only seems to happen with large files, when they are written to disk and pass this threshold. Not an ideal fix, but if I just move this threshold up considerably higher, I'm guessing it would work, and would at least allow me to see something different. I'll try that, and attach the moitor, and report my results. Thanks for the time. Robert On Sat, 17 Jun 2006, Mike Sparr - www.goomzee.com wrote: Martin, http://ethereal.com/ (very easy to use and when you run it, you can choose which network adapter to capture traffic. After you capture, then you can run the viewer to analyze). In addition, I believe AXIS includes a network monitoring tool built into the library so you may want to use that. Perhaps you could tweak it to Monitor other traffic, but again SOAP is http... org.apache.axis.monitor.SOAPMonitorService Hope that helps, Mike On 6/17/06 4:14 PM, Martin Cooper [EMAIL PROTECTED] wrote: On 6/15/06, Robert J. Carr [EMAIL PROTECTED] wrote: I am attempting to use the fileupload package and having strange results. I have a file type form element that I am uploading an xml file through to. The xml file I'm uploading is about 1.1MB . However, when I print some of the metadata about the uploaded FileItem, here's what I get: Do you have any way of capturing what's on the wire, so that we could look at the contents of the incoming request? Maybe Windows Network Monitor or Ethereal or something? Without that, it will be hard to figure out what's going on. -- Martin Cooper content-type: text/xml size: 2363688 (via getSize()) length: 2363688 (via get().length) When I look in my tomcat temp directory, I see a file: upload_00014.xml Which is the correct file, it is 1.1MB and passes diff. However, when I attempt to write the file to disk: item.write(File.createTempFile(portaltest-, null)); I get a file written: portaltest-64578.tmp Which is incorrect, and a size of 2.3 MB (which matches the size above). I'm using the latest 1.1.1 release (but same thing happens with 1.1). To get my fileitems, I make this sequence of calls: FileItemFactory factory = new DiskFileItemFactory(); PortletFileUpload upload = new PortletFileUpload(factory); ListFileItem items = (ListFileItem) upload.parseRequest(request); To add another twist, this seems to work fine for smaller files (less than about 50KB in size). I'm also getting an exception thrown later, and not entirely sure where it is coming from. It may be a red herring, but I'll include it for completeness: java.io.FileNotFoundException: /opt/java/LiferayPro3.6.1/temp/upload__41c20f98_10bd8eb6a9d__7ffe_0002.tm p (No such file or directory) So I have no idea what is going on. My form is pretty basic ... here it is as well: form name=portlet:namespace /fm action=portlet:actionURL / method=post enctype=multipart/form-data input type=file name=portlet:namespace /rdssxml / /form Any help would be appreciated. Are there other upload packages similar to filupload that I could try? I've always found the jakarta tools to be the most consistently well done, but I would like to test just for sanity. Thanks- Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons fileupload
On 6/15/06, Robert J. Carr [EMAIL PROTECTED] wrote: I am attempting to use the fileupload package and having strange results. I have a file type form element that I am uploading an xml file through to. The xml file I'm uploading is about 1.1MB. However, when I print some of the metadata about the uploaded FileItem, here's what I get: Do you have any way of capturing what's on the wire, so that we could look at the contents of the incoming request? Maybe Windows Network Monitor or Ethereal or something? Without that, it will be hard to figure out what's going on. -- Martin Cooper content-type: text/xml size: 2363688 (via getSize()) length: 2363688 (via get().length) When I look in my tomcat temp directory, I see a file: upload_00014.xml Which is the correct file, it is 1.1MB and passes diff. However, when I attempt to write the file to disk: item.write(File.createTempFile(portaltest-, null)); I get a file written: portaltest-64578.tmp Which is incorrect, and a size of 2.3 MB (which matches the size above). I'm using the latest 1.1.1 release (but same thing happens with 1.1). To get my fileitems, I make this sequence of calls: FileItemFactory factory = new DiskFileItemFactory(); PortletFileUpload upload = new PortletFileUpload(factory); ListFileItem items = (ListFileItem) upload.parseRequest(request); To add another twist, this seems to work fine for smaller files (less than about 50KB in size). I'm also getting an exception thrown later, and not entirely sure where it is coming from. It may be a red herring, but I'll include it for completeness: java.io.FileNotFoundException: /opt/java/LiferayPro3.6.1/temp/upload__41c20f98_10bd8eb6a9d__7ffe_0002.tmp (No such file or directory) So I have no idea what is going on. My form is pretty basic ... here it is as well: form name=portlet:namespace /fm action=portlet:actionURL / method=post enctype=multipart/form-data input type=file name=portlet:namespace /rdssxml / /form Any help would be appreciated. Are there other upload packages similar to filupload that I could try? I've always found the jakarta tools to be the most consistently well done, but I would like to test just for sanity. Thanks- Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons fileupload
Martin, http://ethereal.com/ (very easy to use and when you run it, you can choose which network adapter to capture traffic. After you capture, then you can run the viewer to analyze). In addition, I believe AXIS includes a network monitoring tool built into the library so you may want to use that. Perhaps you could tweak it to Monitor other traffic, but again SOAP is http... org.apache.axis.monitor.SOAPMonitorService Hope that helps, Mike On 6/17/06 4:14 PM, Martin Cooper [EMAIL PROTECTED] wrote: On 6/15/06, Robert J. Carr [EMAIL PROTECTED] wrote: I am attempting to use the fileupload package and having strange results. I have a file type form element that I am uploading an xml file through to. The xml file I'm uploading is about 1.1MB. However, when I print some of the metadata about the uploaded FileItem, here's what I get: Do you have any way of capturing what's on the wire, so that we could look at the contents of the incoming request? Maybe Windows Network Monitor or Ethereal or something? Without that, it will be hard to figure out what's going on. -- Martin Cooper content-type: text/xml size: 2363688 (via getSize()) length: 2363688 (via get().length) When I look in my tomcat temp directory, I see a file: upload_00014.xml Which is the correct file, it is 1.1MB and passes diff. However, when I attempt to write the file to disk: item.write(File.createTempFile(portaltest-, null)); I get a file written: portaltest-64578.tmp Which is incorrect, and a size of 2.3 MB (which matches the size above). I'm using the latest 1.1.1 release (but same thing happens with 1.1). To get my fileitems, I make this sequence of calls: FileItemFactory factory = new DiskFileItemFactory(); PortletFileUpload upload = new PortletFileUpload(factory); ListFileItem items = (ListFileItem) upload.parseRequest(request); To add another twist, this seems to work fine for smaller files (less than about 50KB in size). I'm also getting an exception thrown later, and not entirely sure where it is coming from. It may be a red herring, but I'll include it for completeness: java.io.FileNotFoundException: /opt/java/LiferayPro3.6.1/temp/upload__41c20f98_10bd8eb6a9d__7ffe_0002.tm p (No such file or directory) So I have no idea what is going on. My form is pretty basic ... here it is as well: form name=portlet:namespace /fm action=portlet:actionURL / method=post enctype=multipart/form-data input type=file name=portlet:namespace /rdssxml / /form Any help would be appreciated. Are there other upload packages similar to filupload that I could try? I've always found the jakarta tools to be the most consistently well done, but I would like to test just for sanity. Thanks- Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons-FileUpload
You may be hitting the same issue as this: http://issues.apache.org/bugzilla/show_bug.cgi?id=36413 Please try FileUpload 1.1 and see if that resolves the problem. If it doesn't, please provide as much information as possible as comments in the above issue report. -- Martin Cooper On 4/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Good Afternoon to All: I am ver new to the group. We are using the FileUpload.jar. The version is 1.0. We are getting the below exception. Can someone be so kind to explain why this error is showing up. We are using Apache Http Server. Apr 12, 2006 7:05:47 AM EDT Error HTTP chapdpiapp01 c220-s1 ExecuteThread: '65' for queue: 'weblogic.kernel.Default' WLS Kernel BEA-101017 [ServletContext(id=31372791,name=ProductWeb,context-path=/ProductWeb)] Root cause of ServletException. org.apache.commons.fileupload.FileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase .java:429) at org.apache.struts.upload.CommonsMultipartRequestHandler.handleRequest(Co mmonsMultipartRequestHandler.java:233) at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:1209) at org.apache.struts.action.RequestProcessor.processPopulate(RequestProcess or.java:821) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java: 254) at com.company.group.product.web.framework.DefaultRequestProcessor.process( DefaultRequestProcessor.java:55) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(Se rvletStubImpl.java:1006) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl. java:419) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl. java:315) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.r un(WebAppServletContext.java:6718) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSu bject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121 ) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServl etContext.java:3764) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl. java:2644) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178) Thanks you for reading my post. Russ
Re: [commons-fileupload] one parameter, many files
On 5/5/05, Durham David R Jr Ctr 805 CSPTS/SCE [EMAIL PROTECTED] wrote: My understanding is that commons-fileupload will not properly parse fileuploads with the same property name. First, can someone confirm this? I didn't find a bug report on it, but have seen some discussion about it on struts-user. Next part, can someone give me some background regarding whether this is expected to be fixed, won't be fixed, rough idea of what the technical problem, etc? What you're referring to is not an issue with Commons FileUpload, but a limitation of the Struts usage of FileUpload. It will get fixed, although I can't give you a date. I don't recall if there's already a bug report in the Struts bug database for this, but feel free to add one if you don't find one there. -- Martin Cooper Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Commons FileUpload]understanding the source code
You seem to missing the line terminators, the request sent would have looked like this: -7d433743032e Content-Disposition: form-data; name=file1; filename=C:\abc.txt Content-Type: text/plain XYZ -7d433743032e-- They just have to process each line. The blank line between Content-type: and XYZ is important, that separates the headers from the content. Rommel Sharma wrote: Hi, This question is about the Commons FileUpload package. I hope I am posting to the right users list. I am trying to understand the source code, and understand the logic through which the data is extracted. From my understanding: when we use the file input tag to upload a file to the server using the POST method, then the data transferred looks like this: -7d433743032eContent-Disposition: form-data; name=file1; filename=C:\abc.txtContent-Type: text/plainXYZ-7d433743032e-- where the content in my file is XYZ. We can write a code that extracts the filename by parsing the inputstream. Now my question is that how can we extract the content XYZ as the Content-Type could be anything: text/plain, or text/html, or application/octet-stream or something else? We know that the content ends with the boundary (-7d433743032e-- in this case in case of single file uplaod) so we know upto where the content will be, but how do we know the exact starting index of the content as the content type could vary. Also, the content length that I may extract, will give me size including that of the boundary and associated information also, but all I want is of only of the file uplaoded by the client. How did the Commons FileUpload team get across these problem? The source code, although very well written, looks a bit confusing to me. Thanks and Regards, Rommel Sharma. * Disclaimer: This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. * Visit us at http://www.mahindrabt.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jason Lea - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons FileUpload and DiskFileUpload.parseRequest()
On Mon, 24 May 2004, Scott Dudley wrote:
I'm attempting to use org.apache.commons.fileupload in a servlet for the
first time and have run into a snag. See below for my doPost() method.
If my jsp form passes any parameter to the servlet other than the file,
DiskFileUpload.parseRequest() returns an empty list. If only the file
is passed, it works splendidly. What am I doing wrong?
The problem isn't passing the additional parameter, it's attempting to
access it using request.getParameter(). As soon as you do that, the
container is going to consume the servlet input stream - meaning the
contents of the request - at which point it is no longer available for
FileUpload to parse.
Your 'directory' parameter will be available in the list of file items
returned by FileUpload, so you'll need to wait until then to use it.
--
Martin Cooper
From jsp:
form action=servlet/com.telesoft.web.FileUploadServlet
enctype=multipart/form-data method=post
%--
input type=hidden name=directory
value=%=request.getParameter(directory)%
--%
input type=file name=fileName
input type=Submit name=Submit value=Upload
/form
From FileUploadServlet.java:
public void doPost(HttpServletRequest req, HttpServletResponse
res) throws ServletException, IOException {
//String dirName = req.getParameter(directory);
String dirName = /tmp;
if (dirName == null)
throw new ServletException(Required parameter
\directory\ missing);
File directory = new File(dirName);
// guess we could just let these two issues fall to
try/catch block...
if (! directory.isDirectory())
throw new ServletException(directory.getName() + is
not a directory);
if (! directory.canWrite())
throw new ServletException(Cannot write to +
directory.getName());
DiskFileUpload fu = new DiskFileUpload();
// maximum size before a FileUploadException will be thrown
fu.setSizeMax(100);
// maximum size that will be stored in memory
fu.setSizeThreshold(4096);
// the location for saving data that is larger than
getSizeThreshold()
fu.setRepositoryPath(directory.getAbsolutePath());
try {
List fileItems = fu.parseRequest(req);
// if any paramters other than file meta data are passed
to servlet, fileItems.size() == 0
FileItem fi = (FileItem) fileItems.get(0);
fi.write(new File(directory, fi.getName()));
} catch (Exception e) {
e.printStackTrace();
throw new ServletException(e.getMessage());
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Commons-fileupload] FileUploadException: .. Read timed out
Thanks Robert, We are indeed using tomcat (4.2.27), and I've tried your suggestion. But the same problem still occurs. The problem is not that we are trying to upload large files that exceed the upload timeout. In fact this problem only occurs when the form file input is left empty, and no file is uploaded at all at that moment. If any file is specified, uploading works fine. The exception also never occurs when IE6.0 is used as a browser client, neither on XP. It is the combination of using SSL with IE5.5 on windows 2000 and older machines. Below I included the stacktrace after having upgraded to fileupload 1.0 (included in struts 1.1). Wilco. org.apache.commons.fileupload.FileUploadException: Processing of multipart/form-data request failed. Read timed out at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:429) at org.apache.struts.upload.CommonsMultipartRequestHandler.handleRequest(CommonsMultipartRequestHandler.java:233) at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:1209) at org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:821) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:254) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525) From: Robert Leland [EMAIL PROTECTED] Reply-To: Jakarta Commons Users List [EMAIL PROTECTED] To: Jakarta Commons Users List [EMAIL PROTECTED] Subject: Re: [Commons-fileupload] FileUploadException: .. Read timed out Date: Tue, 09 Sep 2003 11:19:18 -0400 Wilco Kasteleijn wrote: Under tomcat in the server.xml there is an upload timeout, I assume in your container there would be an equalivent setting. -Rob Hi, We are having a similar problem as posted before by Daryl Stultz (08 Jul 2003). This exception only occurs under the following conditions: - Usage of SSL; - Win2000 SP4 client or older, with IE5.5; - The form has a file input parameter that is LEFT EMPTY during form submission; Daryl, have you found a solution for this? Anybody else any ideas? See stacktrace below. This is from the previous release of fileupload. But the same problem still occurs with the latest version (1.0). Regards, Wilco. org.apache.commons.fileupload.FileUploadException: Processing of multipart/form-data request failed. Read timed out at org.apache.commons.fileupload.FileUpload.parseRequest(FileUpload.java:462) at org.apache.commons.fileupload.FileUpload.parseRequest(FileUpload.java:304) at org.apache.struts.upload.CommonsMultipartRequestHandler.handleRequest(CommonsMultipartRequestHandler.java:234) at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:943) at org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:784) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:244) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1291) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:502) === Wilco Kasteleijn Bright Alley Knowledge Learning BV www.brightalley.com _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Commons-fileupload] FileUploadException: .. Read timed out
Hi Dennis, Let's see some code! Do you check to make sure the file field was provided before writing? I don't know what would happen if you didn't, but a read timeout is conceivable. I use it with SSL, IE5.5, NS4.7, NS6.1, and NS7.1 with no trouble. Thanks for the tip. But none of my code is excecuted at that point, it never arrives at my action class. The problem occurs during form reading in the struts request processor. Are you running IE5.5 on XP? Because it only happens with windows2000/98 client machines. I have digged into the source code and got a more detailed stacktrace (see below). Regards, Wilco. java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(Unknown Source) at com.sun.net.ssl.internal.ssl.InputRecord.a(Unknown Source) at com.sun.net.ssl.internal.ssl.InputRecord.read(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Unknown Source) at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source) at org.apache.catalina.connector.http.SocketInputStream.fill(SocketInputStream.java:594) at org.apache.catalina.connector.http.SocketInputStream.read(SocketInputStream.java:531) at org.apache.catalina.connector.RequestStream.read(RequestStream.java:189) at org.apache.catalina.connector.http.HttpRequestStream.read(HttpRequestStream.java:214) at java.io.InputStream.read(Unknown Source) at org.apache.catalina.connector.RequestStream.read(RequestStream.java:238) at org.apache.catalina.connector.http.HttpRequestStream.read(HttpRequestStream.java:254) at org.apache.commons.fileupload.MultipartStream.discardBodyData(MultipartStream.java:651) at org.apache.commons.fileupload.MultipartStream.skipPreamble(MultipartStream.java:690) at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:339) at org.apache.struts.upload.CommonsMultipartRequestHandler.handleRequest(CommonsMultipartRequestHandler.java:233) at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:1209) at org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:821) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:254) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525) _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Commons-fileupload] FileUploadException: .. Read timed out
It works with IE5.5 on XP, but not with IE5.5 on 2000? Wow. That sucks! Have you tried different content-types and such in your form (just using plain, ole text/html)? It works with NS on the same 2000 box? And IE6.x? Try using The Proxomitron (a proxy server) to look at the headers being sent by the different OS/browser flavors - you might have to turn off SSL to do this, I can't remember. Can you turn off SSL? Does that work (or not) the same? The clients I've tested on have all been Windoze 2000. The server is Win2K, as well. We're using Oracle's 9iAS web server with OC4J. We're not using Struts - YET! :-P Sorry. Dennis -Original Message- From: Wilco Kasteleijn [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 10, 2003 12:24 PM To: [EMAIL PROTECTED] Subject:RE: [Commons-fileupload] FileUploadException: .. Read timed out Hi Dennis, Let's see some code! Do you check to make sure the file field was provided before writing? I don't know what would happen if you didn't, but a read timeout is conceivable. I use it with SSL, IE5.5, NS4.7, NS6.1, and NS7.1 with no trouble. Thanks for the tip. But none of my code is excecuted at that point, it never arrives at my action class. The problem occurs during form reading in the struts request processor. Are you running IE5.5 on XP? Because it only happens with windows2000/98 client machines. I have digged into the source code and got a more detailed stacktrace (see below). Regards, Wilco. java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(Unknown Source) at com.sun.net.ssl.internal.ssl.InputRecord.a(Unknown Source) at com.sun.net.ssl.internal.ssl.InputRecord.read(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Unknown Source) at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source) at org.apache.catalina.connector.http.SocketInputStream.fill(SocketInputStream.java:594) at org.apache.catalina.connector.http.SocketInputStream.read(SocketInputStream.java:531) at org.apache.catalina.connector.RequestStream.read(RequestStream.java:189) at org.apache.catalina.connector.http.HttpRequestStream.read(HttpRequestStream.java:214) at java.io.InputStream.read(Unknown Source) at org.apache.catalina.connector.RequestStream.read(RequestStream.java:238) at org.apache.catalina.connector.http.HttpRequestStream.read(HttpRequestStream.java:254) at org.apache.commons.fileupload.MultipartStream.discardBodyData(MultipartStream.java:651) at org.apache.commons.fileupload.MultipartStream.skipPreamble(MultipartStream.java:690) at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:339) at org.apache.struts.upload.CommonsMultipartRequestHandler.handleRequest(CommonsMultipartRequestHandler.java:233) at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:1209) at org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:821) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:254) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525) _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
