ICEfaces
  1. ICEfaces
  2. ICE-9273

ace:fileEntry - Add support for Servlet 3 multi-part uploads

    Details

    • Assignee Priority:
      P2
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.), Compatibility/Configuration

      Description

      file-callback (all browsers): new failure in automation (passed in previous regressions on Tomcat6/Mojarra 2.1)
      Fails manually to return MD5 checksum on file upload; passes with Mojarra 2.1.

      Steps:
      - build file-callback tutorial using Mojarra 2.2, and deploy to tomcat7.
      - click on 'Browse' button to upload file:
      C:\svn\repo\qa\trunk\Regression-Icefaces2\Sparkle\Nightly\fileEntry\web\files\1
      - click on 'Get MD5 Checksum' -> no message is rendered on the page.

        Activity

        Hide
        Mark Collette added a comment -

        Tested with the showcase app using Mojarra 2.2, for both regular uploads and callback uploads, and they both worked fine. So this is specific to the tutorial app, and not the ace:fileEntry component itself.

        Show
        Mark Collette added a comment - Tested with the showcase app using Mojarra 2.2, for both regular uploads and callback uploads, and they both worked fine. So this is specific to the tutorial app, and not the ace:fileEntry component itself.
        Hide
        Mark Collette added a comment -

        I had to fix the tutorial build process so that it wouldn't use the hard-coded jar name of "javax.faces.jar", and instead just use whatever jars are in the lib/mojarra folder, since it nows adds the version to the jar file name, like maven would. After that I was able to reproduce the problem with Mojarra 2.2.0.

        Show
        Mark Collette added a comment - I had to fix the tutorial build process so that it wouldn't use the hard-coded jar name of "javax.faces.jar", and instead just use whatever jars are in the lib/mojarra folder, since it nows adds the version to the jar file name, like maven would. After that I was able to reproduce the problem with Mojarra 2.2.0.
        Hide
        Mark Collette added a comment -

        Possibly the earlier test with javax.faces-2.2.0-m15.jar and showcase was in error, or there were changes between javax.faces-2.2.0-m15.jar and javax.faces-2.2.1.jar, but from testing of showcase.war and file-callback-tutorial.war using javax.faces-2.2.1.jar, they both fail with ace:fileEntry uploads.

        The cause seems to be the @MultipartConfig annotation on the FacesServlet, that was not there for Mojarra 2.1.x, which is causing there to be nothing for the commons-upload FileItemIterator. Will investigate using the Servlet 3.0 Parts API directly, although this will affect percent progress pushing, which was initiated by the commons-upload ProgressListener.

        Show
        Mark Collette added a comment - Possibly the earlier test with javax.faces-2.2.0-m15.jar and showcase was in error, or there were changes between javax.faces-2.2.0-m15.jar and javax.faces-2.2.1.jar, but from testing of showcase.war and file-callback-tutorial.war using javax.faces-2.2.1.jar, they both fail with ace:fileEntry uploads. The cause seems to be the @MultipartConfig annotation on the FacesServlet, that was not there for Mojarra 2.1.x, which is causing there to be nothing for the commons-upload FileItemIterator. Will investigate using the Servlet 3.0 Parts API directly, although this will affect percent progress pushing, which was initiated by the commons-upload ProgressListener.
        Hide
        Mark Collette added a comment -

        Had to reconcile code that handles \ escaping of ; ' " in the file names with IE full path handling that removes file path info and uses the file-system separator which is \ on Windows.

        Show
        Mark Collette added a comment - Had to reconcile code that handles \ escaping of ; ' " in the file names with IE full path handling that removes file path info and uses the file-system separator which is \ on Windows.
        Hide
        Mark Collette added a comment -

        The file-callback-tutorial progress issue was due to old app CSS that predated the change to using themeroller for the fileEntry styling. Removed it.

        Show
        Mark Collette added a comment - The file-callback-tutorial progress issue was due to old app CSS that predated the change to using themeroller for the fileEntry styling. Removed it.
        Hide
        Mark Collette added a comment -

        Re-wrote the upload handling to more separate the Parts and Apache Commons code paths, to accommodate the Parts write and delete methods. There is essentially no server initiated progress though, and so will require investigation of client-side progress, or some kind of server interception of request bytes before they become parsed and cached Part objects.

        Show
        Mark Collette added a comment - Re-wrote the upload handling to more separate the Parts and Apache Commons code paths, to accommodate the Parts write and delete methods. There is essentially no server initiated progress though, and so will require investigation of client-side progress, or some kind of server interception of request bytes before they become parsed and cached Part objects.
        Hide
        Mark Collette added a comment - - edited

        Mojarra 2.2.1 seems to be part-way through developing the necessary support for file uploading via XHR[2]. Not enough hooks are in place for us to use them and add the file sending, without patching jsf.js itself. But possibly we can use the "begin" event to add progress event listening.

        1856:    sendEvent(req.xmlReq, req.context, "begin");
        1857:    req.xmlReq.send(content);
        

        They're using the XHR1 send(String) call instead of the XHR2 send(FormData) call that would encapsulate form fields and file fields.

        var formData = new FormData(form);             // Existing form fields including input type=file
        formData.append('secret_token', '1234567890'); // Additional params as encoded in lines 1826-1833
        
        Show
        Mark Collette added a comment - - edited Mojarra 2.2.1 seems to be part-way through developing the necessary support for file uploading via XHR [2] . Not enough hooks are in place for us to use them and add the file sending, without patching jsf.js itself. But possibly we can use the "begin" event to add progress event listening. 1856: sendEvent(req.xmlReq, req.context, "begin" ); 1857: req.xmlReq.send(content); They're using the XHR1 send(String) call instead of the XHR2 send(FormData) call that would encapsulate form fields and file fields. var formData = new FormData(form); // Existing form fields including input type=file formData.append('secret_token', '1234567890'); // Additional params as encoded in lines 1826-1833
        Hide
        Mark Collette added a comment -

        Committed everything, which allows for proper uploading in all the scenarios. The only issue being that there is no progress in Servlet 3 + Mojarra 2.2.x, but that has been spun off into ICE-9516.

        icefaces3 trunk
        Subversion 37399

        Show
        Mark Collette added a comment - Committed everything, which allows for proper uploading in all the scenarios. The only issue being that there is no progress in Servlet 3 + Mojarra 2.2.x, but that has been spun off into ICE-9516. icefaces3 trunk Subversion 37399
        Hide
        Mark Collette added a comment -

        Fixed minor regression where the size for failed file upload should be zero.

        icefaces3 trunk
        Subversion 37714

        Show
        Mark Collette added a comment - Fixed minor regression where the size for failed file upload should be zero. icefaces3 trunk Subversion 37714
        Hide
        Arturo Zambrano added a comment -

        Reopening issue.

        After investigating ICE-9589, it was found that code committed for solving this issue (ICE-9273) contains a call to HttpServletRequest.getParts() and use of javax.servlet.http.Part objects, which are only available in the Servlet 3.0 API, and not in previous Servlet versions. Thus, ace:fileEntry is not working on Tomcat 6, for example, and any other server that uses a Servlet API earlier than 3.0. Refactoring this code will be necessary to make ace:fileEntry work with earlier Servler API's.

        Show
        Arturo Zambrano added a comment - Reopening issue. After investigating ICE-9589, it was found that code committed for solving this issue ( ICE-9273 ) contains a call to HttpServletRequest.getParts() and use of javax.servlet.http.Part objects, which are only available in the Servlet 3.0 API, and not in previous Servlet versions. Thus, ace:fileEntry is not working on Tomcat 6, for example, and any other server that uses a Servlet API earlier than 3.0. Refactoring this code will be necessary to make ace:fileEntry work with earlier Servler API's.
        Hide
        Arturo Zambrano added a comment -

        Committed fix at revision 38314. Replaced use of javax.servlet.http.Part with use of Apache Commons FileUpload classes in order to restore compatibility with Servlet 2.5 API.

        Show
        Arturo Zambrano added a comment - Committed fix at revision 38314. Replaced use of javax.servlet.http.Part with use of Apache Commons FileUpload classes in order to restore compatibility with Servlet 2.5 API.
        Hide
        Liana Munroe added a comment - - edited

        The test case in this JIRA is confirmed fixed Tomcat 6, 7, IE 7, 8, 9, 10, FF 3.6, 21, Chrome 29. Revision # 38328.
        Regression tests for fileEntry were run in Tomcat 6 and 7 with FF 21, IE 9 and Chrome 29. All passed manually.

        Show
        Liana Munroe added a comment - - edited The test case in this JIRA is confirmed fixed Tomcat 6, 7, IE 7, 8, 9, 10, FF 3.6, 21, Chrome 29. Revision # 38328. Regression tests for fileEntry were run in Tomcat 6 and 7 with FF 21, IE 9 and Chrome 29. All passed manually.

          People

          • Assignee:
            Ken Fyten
            Reporter:
            Carmen Cristurean
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: