ICEfaces
  1. ICEfaces
  2. ICE-10839

ace:fileEntry - max file size messages not shown when using <multipart-config> settings

          Details

          • Assignee Priority:
            P2
          • Support Case References:
          • Workaround Exists:
            Yes
          • Workaround Description:
            Comment out 'max-file-size' and 'max-request-size' tags in <multipart-config> setting in the web.xml and use ace:fileEntry's 'maxFileSize' and 'maxFileSizeMessage' attributes instead.

            Description

            When using the file size <multipart-config> settings as mentioned in the wiki docs, an error is thrown server side but the client side is not updated. An exception is thrown in on the server side but the progress bar on the client continues to be active.

            This can be reproduced with the Showcase demo. The web.xml needs to be updated to use the <multipart-config> settings.

            Error stack trace:
            04-Nov-2015 10:48:46.069 WARNING [http-nio-8084-exec-5] org.icefaces.ace.component.fileentry.FileEntryUpload.afterPhase Problem reading multi-part form upload, likely due to a file upload being cut off from the client losing their network connection or closing their browser tab or window.
             java.lang.IllegalStateException: org.apache.tomcat.util.http.fileupload.FileUploadBase$SizeLimitExceededException: the request was rejected because its size (151940648) exceeds the configured maximum (52428800)
            at org.apache.catalina.connector.Request.parseParts(Request.java:2707)
            at org.apache.catalina.connector.Request.parseParameters(Request.java:2951)
            at org.apache.catalina.connector.Request.getParameter(Request.java:1091)
            at org.apache.catalina.connector.RequestFacade.getParameter(RequestFacade.java:380)
            at org.netbeans.modules.web.monitor.server.MonitorRequestWrapper.getParameter(MonitorRequestWrapper.java:199)
            at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:145)
            at org.icefaces.util.ClientDescriptor.getInstance(ClientDescriptor.java:73)
            at org.icefaces.impl.application.ClientDescriptorSetup.isSessionAwareResourceRequest(ClientDescriptorSetup.java:38)
            at org.icefaces.impl.application.SessionAwareResourceHandlerWrapper.isResourceRequest(SessionAwareResourceHandlerWrapper.java:32)
            at org.icefaces.impl.application.SessionTimeoutMonitor.isSessionAwareResourceRequest(SessionTimeoutMonitor.java:41)
            at org.icefaces.impl.application.SessionAwareResourceHandlerWrapper.isResourceRequest(SessionAwareResourceHandlerWrapper.java:32)
            at javax.faces.application.ResourceHandlerWrapper.isResourceRequest(ResourceHandlerWrapper.java:166)
            at javax.faces.application.ResourceHandlerWrapper.isResourceRequest(ResourceHandlerWrapper.java:166)
            at javax.faces.application.ResourceHandlerWrapper.isResourceRequest(ResourceHandlerWrapper.java:166)
            at javax.faces.application.ResourceHandlerWrapper.isResourceRequest(ResourceHandlerWrapper.java:166)
            at javax.faces.application.ResourceHandlerWrapper.isResourceRequest(ResourceHandlerWrapper.java:166)
            at org.icefaces.impl.util.CharacterEncodingHandler.isResourceRequest(CharacterEncodingHandler.java:73)
            at javax.faces.application.ResourceHandlerWrapper.isResourceRequest(ResourceHandlerWrapper.java:166)
            at javax.faces.application.ResourceHandlerWrapper.isResourceRequest(ResourceHandlerWrapper.java:166)
            at javax.faces.webapp.FacesServlet.service(FacesServlet.java:642)
            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
            at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
            at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:393)
            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
            at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
            at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
            at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503)
            at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136)
            at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
            at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
            at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
            at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:526)
            at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
            at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:655)
            at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
            at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1566)
            at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1523)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
            at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
            at java.lang.Thread.run(Thread.java:745)
            Caused by: org.apache.tomcat.util.http.fileupload.FileUploadBase$SizeLimitExceededException: the request was rejected because its size (151940648) exceeds the configured maximum (52428800)
            at org.apache.tomcat.util.http.fileupload.FileUploadBase$FileItemIteratorImpl.<init>(FileUploadBase.java:811)
            at org.apache.tomcat.util.http.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:256)
            at org.apache.tomcat.util.http.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:280)
            at org.apache.catalina.connector.Request.parseParts(Request.java:2640)
            ... 44 more

            1. Zip Archive
              Case13600Example.zip
              21 kB
              Arran Mccullough
            2. Zip Archive
              Case13600ExampleWAR.zip
              9.29 MB
              Arran Mccullough

              Activity

              Ascending order - Click to sort in descending order
              Arran Mccullough created issue -
              Hide
              Permalink
              Arran Mccullough added a comment -

              Attached test case that shows this issue.

              Steps:

              • Load welcomeICEfaces.jsf
              • Upload a file that is larger than 60MB. An error is shown in the server logs but the client progress bar remains active.
              Show
              Arran Mccullough added a comment - Attached test case that shows this issue. Steps: Load welcomeICEfaces.jsf Upload a file that is larger than 60MB. An error is shown in the server logs but the client progress bar remains active.
              Arran Mccullough made changes -
              Field Original Value New Value
              Attachment Case13600Example.zip [ 21981 ]
              Attachment Case13600ExampleWAR.zip [ 21982 ]
              Ken Fyten made changes -
              Fix Version/s EE-4.1.0.GA [ 12171 ]
              Fix Version/s EE-3.3.0.GA_P04 [ 12270 ]
              Ken Fyten made changes -
              Assignee Mircea Toma [ mircea.toma ]
              Hide
              Permalink
              Mircea Toma added a comment - - edited

              The issue will not occur when the application was started right after the application server was started. Also window scope needs to not be activated by a window scoped bean or org.icefaces.lazyWindowScope=false context parameter.

              The fix will register the pushID with the upload progress group in case window scope is not enabled for the application. When window scope si disabled a window scope map is reused for all windows. Before the fix the pushID corresponding to the file entry was kept around in the same window scope map (saved in the session) which caused the component to skip its registration with ICEpush.

              Show
              Mircea Toma added a comment - - edited The issue will not occur when the application was started right after the application server was started. Also window scope needs to not be activated by a window scoped bean or org.icefaces.lazyWindowScope=false context parameter. The fix will register the pushID with the upload progress group in case window scope is not enabled for the application. When window scope si disabled a window scope map is reused for all windows. Before the fix the pushID corresponding to the file entry was kept around in the same window scope map (saved in the session) which caused the component to skip its registration with ICEpush.
              Mircea Toma made changes -
              Status Open [ 1 ] Resolved [ 5 ]
              Resolution Fixed [ 1 ]
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #47959 Thu Feb 18 14:25:01 MST 2016 mircea.toma ICE-10839 Register the pushID with the upload progress group in case window scope is not enabled for the application and a window scope map is reused for all windows.
              Files Changed
              Commit graph MODIFY /icefaces4/trunk/icefaces/ace/component/src/org/icefaces/ace/component/fileentry/FileEntryFormSubmit.java
              Ken Fyten made changes -
              Resolution Fixed [ 1 ]
              Status Resolved [ 5 ] Reopened [ 4 ]
              Hide
              Permalink
              Mircea Toma added a comment -

              No, there's no need for org.icefaces.lazyWindowScope=false. I will run the test again.

              Show
              Mircea Toma added a comment - No, there's no need for org.icefaces.lazyWindowScope=false . I will run the test again.
              Hide
              Permalink
              Mircea Toma added a comment -

              The FileUploadBase$SizeLimitExceededException is thrown when servlet container will detect that the upload is larger than the limits defined in <multipart-config> web.xml tag. Unfortunately the servlet container will abort the response right away thus blocking any chance of responding with a partial update that could show the error message.
              To work around this issue an asynchronous update could be triggered which should show the message. But FileEntryUpload.afterPhase method is called multiple times for a multipart request which hiders any chance of showing a message that will persist on the page.

              Eventually this issue could be fixed but the gains are so minimal that is not worth increasing the complexity of this component. File upload limits can be easily defined in file entry's attributes and uploading a file passed the size threshold will have the validation/error messages rendered as expected.

              Show
              Mircea Toma added a comment - The FileUploadBase$SizeLimitExceededException is thrown when servlet container will detect that the upload is larger than the limits defined in <multipart-config> web.xml tag. Unfortunately the servlet container will abort the response right away thus blocking any chance of responding with a partial update that could show the error message. To work around this issue an asynchronous update could be triggered which should show the message. But FileEntryUpload.afterPhase method is called multiple times for a multipart request which hiders any chance of showing a message that will persist on the page. Eventually this issue could be fixed but the gains are so minimal that is not worth increasing the complexity of this component. File upload limits can be easily defined in file entry's attributes and uploading a file passed the size threshold will have the validation/error messages rendered as expected.
              Mircea Toma made changes -
              Status Reopened [ 4 ] Resolved [ 5 ]
              Resolution Won't Fix [ 2 ]
              Mircea Toma made changes -
              Workaround Description Comment out the <multipart-config> setting in the web.xml and use the ace:fileEntry maxFileSize and maxFileSizeMessage attributes. Comment out 'max-file-size' and 'max-request-size' tags in <multipart-config> setting in the web.xml and use ace:fileEntry's 'maxFileSize' and 'maxFileSizeMessage' attributes instead.
              Ken Fyten made changes -
              Affects Version/s 4.0 [ 11382 ]
              Affects Version/s 3.3 [ 10370 ]
              Hide
              Permalink
              Ken Fyten added a comment -

              Documented the workaround as a Known Issue in http://www.icesoft.org/wiki/display/ICE/FileEntry

              Show
              Ken Fyten added a comment - Documented the workaround as a Known Issue in http://www.icesoft.org/wiki/display/ICE/FileEntry
              Hide
              Permalink
              Carmen Cristurean added a comment - - edited

              Tested workaround with attached test case on ICEfaces4 trunk r48469, IE11, FF41, Chrome48: the workaround only works if the ace:fileEntry's 'maxFileSize' and 'maxFileSizeMessage' attributes are used, and the <multipart-config> tag is removed from the web.xml.
              Using also the <multipart-config> entries with a greater max file size value than the one specified by the ace:fileEntry's 'maxFileSize' attribute, as recommended in the wiki documentation for ace:fileEntry, still triggers the server error from the description of this JIRA.

              Show
              Carmen Cristurean added a comment - - edited Tested workaround with attached test case on ICEfaces4 trunk r48469, IE11, FF41, Chrome48: the workaround only works if the ace:fileEntry's 'maxFileSize' and 'maxFileSizeMessage' attributes are used, and the <multipart-config> tag is removed from the web.xml. Using also the <multipart-config> entries with a greater max file size value than the one specified by the ace:fileEntry's 'maxFileSize' attribute, as recommended in the wiki documentation for ace:fileEntry, still triggers the server error from the description of this JIRA.
              Hide
              Permalink
              Ken Fyten added a comment -

              I updated the Wiki page to clarify that the multipart-config entries cannot be used if the ace:fileEntry component error message is desired.

              Show
              Ken Fyten added a comment - I updated the Wiki page to clarify that the multipart-config entries cannot be used if the ace:fileEntry component error message is desired.
              Hide
              Permalink
              Ken Fyten added a comment -

              There is an issue with the workaround, in that ace:fileEntry will not function on certain servers without the <multipart-config><max-file-size> web.xml entry.

              Showcase > fileEntry demos pass on WAS 8.5.5.4 when using the showcase <multipart-config> default entries.

              File uploads don't seem to work on any of the showcase demos on WAS 8.5.5.4, when using below configuration with the <max-file-size> entry disabled in <multipart-config>; this configuration works only on Tomcat7, displaying a validation "Submitted file is too large" message, when the file has the size above the value set in the ace:fileEntry's 'maxFileSize' attribute on the page.

              <multipart-config>
              <!-max-file-size>52428800</max-file-size->
              <max-request-size>52428800</max-request-size>
              <file-size-threshold>0</file-size-threshold>
              </multipart-config>

              Regards,
              Carmen

              Show
              Ken Fyten added a comment - There is an issue with the workaround, in that ace:fileEntry will not function on certain servers without the <multipart-config><max-file-size> web.xml entry. Showcase > fileEntry demos pass on WAS 8.5.5.4 when using the showcase <multipart-config> default entries. File uploads don't seem to work on any of the showcase demos on WAS 8.5.5.4, when using below configuration with the <max-file-size> entry disabled in <multipart-config>; this configuration works only on Tomcat7, displaying a validation "Submitted file is too large" message, when the file has the size above the value set in the ace:fileEntry's 'maxFileSize' attribute on the page. <multipart-config> <!- max-file-size>52428800</max-file-size -> <max-request-size>52428800</max-request-size> <file-size-threshold>0</file-size-threshold> </multipart-config> Regards, Carmen
              Ken Fyten made changes -
              Resolution Won't Fix [ 2 ]
              Status Resolved [ 5 ] Reopened [ 4 ]
              Ken Fyten made changes -
              Assignee Priority P2 [ 10011 ]
              Hide
              Permalink
              Mircea Toma added a comment - - edited

              Carmen, can you please retest file upload in showcase but make sure that both max-file-size and max-request-size are commented out? If that won't work increase both max-file-size and max-request-size to a value higher than the one defined in file entry's _ maxFileSize_ attribute.

              Show
              Mircea Toma added a comment - - edited Carmen, can you please retest file upload in showcase but make sure that both max-file-size and max-request-size are commented out? If that won't work increase both max-file-size and max-request-size to a value higher than the one defined in file entry's _ maxFileSize_ attribute.
              Hide
              Permalink
              Carmen Cristurean added a comment - - edited

              Tested with with Jenkins IF4 trunk Build# 1842, with showcase > fileEntry > Overview demo:
              If commenting out both <max-file-size> and <max-request-size>, the behavior is the same on WAS 8.5.5.4, as if disabling only the <max-file-size>, with the default values for the fileEntry's maxFileSize, as specified on Fileentry.xhtml (maxFileSize="6291456"). Trying to upload a larger file is not allowed, but there is no message rendered on page.
              If using the same .war file on Tomcat7, the "Submitted file is too large" validation message is rendered.

              If using the default showcase on WAS 8.5.5.4 (this has both max-file-size and max-request-size with higher values than the one defined in the fileEntry's maxFileSize), the fileEntry > Overview demo rendered the "Submitted file is too large" validation message when trying to upload a larger file.

              Show
              Carmen Cristurean added a comment - - edited Tested with with Jenkins IF4 trunk Build# 1842, with showcase > fileEntry > Overview demo: If commenting out both <max-file-size> and <max-request-size>, the behavior is the same on WAS 8.5.5.4, as if disabling only the <max-file-size>, with the default values for the fileEntry's maxFileSize, as specified on Fileentry.xhtml (maxFileSize="6291456"). Trying to upload a larger file is not allowed, but there is no message rendered on page. If using the same .war file on Tomcat7, the "Submitted file is too large" validation message is rendered. If using the default showcase on WAS 8.5.5.4 (this has both max-file-size and max-request-size with higher values than the one defined in the fileEntry's maxFileSize), the fileEntry > Overview demo rendered the "Submitted file is too large" validation message when trying to upload a larger file.
              Hide
              Permalink
              Ken Fyten added a comment -

              Okay, that is the expected behaviour on WS 8.

              I've edited the ace:fileEntry Wiki page entry for this as follows:

              Note that when using the Servlet 3 <max-file-size> and <max-request-size> tags in the <multipart-config> settings in the web.xml with ace:fileEntry no error messages will be displayed by the component if an upload attempt is made with a file that is too large. If a component error message is desired it is necessary to also specify the ace:fileEntry's 'maxFileSize' and 'maxFileSizeMessage' attributes with values that are less than (smaller) than those specified in the <multipart-config> entries in the web.xml.

              Show
              Ken Fyten added a comment - Okay, that is the expected behaviour on WS 8. I've edited the ace:fileEntry Wiki page entry for this as follows: Note that when using the Servlet 3 <max-file-size> and <max-request-size> tags in the <multipart-config> settings in the web.xml with ace:fileEntry no error messages will be displayed by the component if an upload attempt is made with a file that is too large. If a component error message is desired it is necessary to also specify the ace:fileEntry's 'maxFileSize' and 'maxFileSizeMessage' attributes with values that are less than (smaller) than those specified in the <multipart-config> entries in the web.xml.
              Ken Fyten made changes -
              Status Reopened [ 4 ] Resolved [ 5 ]
              Resolution Fixed [ 1 ]
              Ken Fyten made changes -
              Fix Version/s EE-4.1.0.BETA [ 13072 ]
              Ken Fyten made changes -
              Fix Version/s 4.2.BETA [ 13091 ]
              Fix Version/s 4.2 [ 12870 ]
              Ken Fyten made changes -
              Status Resolved [ 5 ] Closed [ 6 ]

                People

                • Assignee:
                  Mircea Toma
                  Reporter:
                  Arran Mccullough
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  4 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: