Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 1.5.1
-
Component/s: ICE-Components
-
Labels:None
-
Environment:Operating System: All
Platform: All
Description
Tested 1.5.2 ICEfaces + 1.5.2 (JSP) component-showcase's File Upload component.
I found that if I type in a fake file name, to make it have an upload
error, then it will show the previously working filename with the current error
message.
1. Click Browse and select a valid file. Let's say it's "ABC.zip"
2. Click Upload. It should say:
100%
File Name: ABC.zip
Content Type: application/zip
3. Type in a bogus filename, like "XYZ123"
4. Click Upload. It will now say:
100%
File Name: ABC.zip
Content Type: application/zip
* This is not a valid file
I think that the progress should be 0%, and it should use the new filename.
Oh, and this exception is thrown on the server:
org.apache.commons.fileupload.FileUploadException: This is not a valid file
at
com.icesoft.faces.component.inputfile.DiskFileUpload.parseRequest(DiskFileUpload.java:175)
at
com.icesoft.faces.component.inputfile.FileUploadServlet.processMultipartContent(FileUploadServlet.java:163)
at
com.icesoft.faces.component.inputfile.FileUploadServlet.doPost(FileUploadServlet.java:149)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:644)
I found that if I type in a fake file name, to make it have an upload
error, then it will show the previously working filename with the current error
message.
1. Click Browse and select a valid file. Let's say it's "ABC.zip"
2. Click Upload. It should say:
100%
File Name: ABC.zip
Content Type: application/zip
3. Type in a bogus filename, like "XYZ123"
4. Click Upload. It will now say:
100%
File Name: ABC.zip
Content Type: application/zip
* This is not a valid file
I think that the progress should be 0%, and it should use the new filename.
Oh, and this exception is thrown on the server:
org.apache.commons.fileupload.FileUploadException: This is not a valid file
at
com.icesoft.faces.component.inputfile.DiskFileUpload.parseRequest(DiskFileUpload.java:175)
at
com.icesoft.faces.component.inputfile.FileUploadServlet.processMultipartContent(FileUploadServlet.java:163)
at
com.icesoft.faces.component.inputfile.FileUploadServlet.doPost(FileUploadServlet.java:149)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:644)
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
This bug has been fixed, it was an application level fix.