Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.2
    • Component/s: Ajax/JavaScript
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Macintosh

    • Issuezilla Id:
      802
    • Status Whiteboard:
      Hide

      size_medium importance_large draft

      Show
      size_medium importance_large draft
    • Tags:

      Description

      The main issue with the current implementation is, that fileupload the ajax way
      is not working properly.

      The problem simply is, that fileupload component and multipart form requests
      both are a second class citizen in the JEE world and html generally.
      There is no way to submit a fileupload via ajax currently, however there is an
      iframe based method to do it.

      But for that an iframe transport layer is missing, since the current spec only
      talks abut queued asynchronous xhr requests.

      see http://www.openjs.com/articles/ajax/ajax_file_upload/

      for more information....

      1. 20110613-i_spec_802_mods.txt
        3 kB
        Ed Burns
      2. 20111208-i_spec_802-mods.patch
        84 kB
        Ed Burns
      3. 20121102-werpu-AjaxFileupload.odt
        16 kB
        Ed Burns

        Issue Links

          Activity

          Hide
          Ed Burns added a comment -

          New features, 2.1.

          Show
          Ed Burns added a comment - New features, 2.1.
          Hide
          Ed Burns added a comment -

          triage

          Show
          Ed Burns added a comment - triage
          Hide
          Ed Burns added a comment -

          Comments from issue 647 Note that from a spec perspective, I believe that the main issue is that
          jsf.ajax.response() expects a XHR
          object, which it uses to grab the responseXML. However, XHR cannot be used in the multi-part form case
          (requires iframe-based postback), and as such no XHR object is available to pass off to jsf.ajax.response().

          Show
          Ed Burns added a comment - Comments from issue 647 Note that from a spec perspective, I believe that the main issue is that jsf.ajax.response() expects a XHR object, which it uses to grab the responseXML. However, XHR cannot be used in the multi-part form case (requires iframe-based postback), and as such no XHR object is available to pass off to jsf.ajax.response().
          Hide
          Ed Burns added a comment -
              • Issue 647 has been marked as a duplicate of this issue. ***
          Show
          Ed Burns added a comment - Issue 647 has been marked as a duplicate of this issue. ***
          Hide
          Ed Burns added a comment -

          adf keyword

          Show
          Ed Burns added a comment - adf keyword
          Hide
          Ed Burns added a comment -

          Change target milestone.

          Show
          Ed Burns added a comment - Change target milestone.
          Hide
          rogerk added a comment -

          triage - Folks have been asking for this.

          Show
          rogerk added a comment - triage - Folks have been asking for this.
          Hide
          ganeshpuri added a comment -

          would be great to be able to do AJAX uploads with 2.1

          Show
          ganeshpuri added a comment - would be great to be able to do AJAX uploads with 2.1
          Hide
          werpu12 added a comment -

          Ok I am doing some prototyping on this issue within the realms of myfaces (since
          I am not allowed to do that for Mojarra)
          So far I have something preliminary up and running which has yet to be committed
          which pushes the current lifecycle over iframes insteas of xhr. However I found
          something in the spec which is some sort of a blocker. The spec requires for a
          valid ajax request that Faces-Request:partial/ajax is set in the request header.
          I do not think you can tamper on form level (which in fact the iframe solution
          is) with that. The result of leaving it out is that the impl thinks this is not
          an ajax request and then renders the full page instead of the response xml.

          I am going to investigate further if setting the request header is possible on
          the iframe solution. Otherwise we have to revamp the spec here a little bit.

          Show
          werpu12 added a comment - Ok I am doing some prototyping on this issue within the realms of myfaces (since I am not allowed to do that for Mojarra) So far I have something preliminary up and running which has yet to be committed which pushes the current lifecycle over iframes insteas of xhr. However I found something in the spec which is some sort of a blocker. The spec requires for a valid ajax request that Faces-Request:partial/ajax is set in the request header. I do not think you can tamper on form level (which in fact the iframe solution is) with that. The result of leaving it out is that the impl thinks this is not an ajax request and then renders the full page instead of the response xml. I am going to investigate further if setting the request header is possible on the iframe solution. Otherwise we have to revamp the spec here a little bit.
          Hide
          werpu12 added a comment -

          Ok the issue with the current specification in the ajax dection and triggering
          of the partial mechanisms is following. I was able to patch the
          PartialViewHandler up so that the entire lifecycle works with the iframe transport.

          The problem really is we currently have two mechanisms, one identifying that it
          is a partial request, the other one, that it is an Ajax request.
          Both work over request headers, for the iframe case we have to weaken the spec
          here a little bit to allow the same over
          request parameters, since there seems to be no way to submit a new header param
          via a normal form submit.

          The idea is following, introduce a third type, iframe request, and allow both
          ajax request, iframe request and partial request also be submitted over simple
          request parameters instead of header params (so both type of values can trigger
          a valid partial lifecycle a request header parameter or a normal request parameter)
          Once a valid iframe request can trigger the partial lifecycle everything else
          behaves just as it would in the xhr case (for the server both usecases are just
          post requests)

          As for the proposed mechanism. My personal idea is to enqueue an iframe request
          just like we would a normal xhr post request in our asynchronous queue and just
          treat it from outside like we we an xhr request. I have this running for most
          browsers already I just have a sync issue for heavy load on IE6, which I will
          investigate later into, but the pattern looks good to me that it might be
          implementable.

          (see the preliminary snapshot code here http://www.pastebin.org/396667 and
          http://www.pastebin.org/396646 from my myfaces based prototype)
          The reason for this is synchronisation issues which the queue eliminates.

          As how and when we trigger the mechanism is a little bit unclear to me still, my
          personal guess is that an auto switch between xhr and iframe in case of an
          embedded executed fileupload might make the most sense to keep the api simple),
          I will try to find out more once my prototype can finally do the fileupload.

          Show
          werpu12 added a comment - Ok the issue with the current specification in the ajax dection and triggering of the partial mechanisms is following. I was able to patch the PartialViewHandler up so that the entire lifecycle works with the iframe transport. The problem really is we currently have two mechanisms, one identifying that it is a partial request, the other one, that it is an Ajax request. Both work over request headers, for the iframe case we have to weaken the spec here a little bit to allow the same over request parameters, since there seems to be no way to submit a new header param via a normal form submit. The idea is following, introduce a third type, iframe request, and allow both ajax request, iframe request and partial request also be submitted over simple request parameters instead of header params (so both type of values can trigger a valid partial lifecycle a request header parameter or a normal request parameter) Once a valid iframe request can trigger the partial lifecycle everything else behaves just as it would in the xhr case (for the server both usecases are just post requests) As for the proposed mechanism. My personal idea is to enqueue an iframe request just like we would a normal xhr post request in our asynchronous queue and just treat it from outside like we we an xhr request. I have this running for most browsers already I just have a sync issue for heavy load on IE6, which I will investigate later into, but the pattern looks good to me that it might be implementable. (see the preliminary snapshot code here http://www.pastebin.org/396667 and http://www.pastebin.org/396646 from my myfaces based prototype) The reason for this is synchronisation issues which the queue eliminates. As how and when we trigger the mechanism is a little bit unclear to me still, my personal guess is that an auto switch between xhr and iframe in case of an embedded executed fileupload might make the most sense to keep the api simple), I will try to find out more once my prototype can finally do the fileupload.
          Hide
          Ed Burns added a comment -
          Show
          Ed Burns added a comment - Please make sure to look at https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi? id=690
          Hide
          Ed Burns added a comment -
          Show
          Ed Burns added a comment - Also make sure to look at https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=861
          Hide
          Ed Burns added a comment -

          Werner suggests the attribute set for t:inputFileUpload as a guide

          http://www.jsftoolbox.com/documentation/tomahawk/09-TagReference/tomahawk-inputFileUpload.html

          Show
          Ed Burns added a comment - Werner suggests the attribute set for t:inputFileUpload as a guide http://www.jsftoolbox.com/documentation/tomahawk/09-TagReference/tomahawk-inputFileUpload.html
          Hide
          Ed Burns added a comment -

          Even though Werner has done most of the preparatory work on this issue, I still have to move it to JSF
          2.2.

          Show
          Ed Burns added a comment - Even though Werner has done most of the preparatory work on this issue, I still have to move it to JSF 2.2.
          Hide
          markcolletteice added a comment - - edited

          In ICEfaces ACE, the fileEntry component uses the [hidden] iframe technique. We have to fake out the partial/ajax request, as well as extract the uploaded file(s) and translate the multi-part request to not be multi-part, so that JSF will run. And then in the browser, when handling the response, we have to fake out the XHR response object, using what we get from the iframe response, so that page updates will be handled.

          It would be nice to collaborate on moving parts of this into JSF, so that everyone's different file upload components could be built on a common infrastructure.

          One critical issue to us is that we don't follow the pattern of simply sticking the file contents into a temporary byte[] or file, like the other component frameworks do. We allow for either directly writing the file to the end file-system destination that the application specified, or using a callback interface for chunking the file data, without buffering the whole file, to the application, so that it can virus scan the file contents, or re-transmit it to another server via a socket, or write it to a database. So, we'd like the file processing to be custom for the component framework, that way we're not limited by a lowest common denominator handling of file data.

          http://wiki.icefaces.org/display/ICE/FileEntry
          http://www.icefaces.org/docs/v2_latest/ace/tld/ace/fileEntry.html
          http://wiki.icefaces.org/display/ICE/Incremental+Upload+Processing+Using+FileEntryCallback

          Show
          markcolletteice added a comment - - edited In ICEfaces ACE, the fileEntry component uses the [hidden] iframe technique. We have to fake out the partial/ajax request, as well as extract the uploaded file(s) and translate the multi-part request to not be multi-part, so that JSF will run. And then in the browser, when handling the response, we have to fake out the XHR response object, using what we get from the iframe response, so that page updates will be handled. It would be nice to collaborate on moving parts of this into JSF, so that everyone's different file upload components could be built on a common infrastructure. One critical issue to us is that we don't follow the pattern of simply sticking the file contents into a temporary byte[] or file, like the other component frameworks do. We allow for either directly writing the file to the end file-system destination that the application specified, or using a callback interface for chunking the file data, without buffering the whole file, to the application, so that it can virus scan the file contents, or re-transmit it to another server via a socket, or write it to a database. So, we'd like the file processing to be custom for the component framework, that way we're not limited by a lowest common denominator handling of file data. http://wiki.icefaces.org/display/ICE/FileEntry http://www.icefaces.org/docs/v2_latest/ace/tld/ace/fileEntry.html http://wiki.icefaces.org/display/ICE/Incremental+Upload+Processing+Using+FileEntryCallback
          Hide
          Neil Griffin added a comment -

          I'm very happy to see that Ajax-based file upload is being discussed. But for the sake of completeness, I think that the old Web 1.0 multipart/form-data technique should be supported, as was discussed in http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-690

          In my comments there,mentioned that I implemented a solution in the PortletFaces Bridge. It's working quite nicely – no need for Servlet 3.0, no need for a filter. Everything works great. Making this work in a Servlet-based JSF like Mojarra should be a piece of cake.

          Show
          Neil Griffin added a comment - I'm very happy to see that Ajax-based file upload is being discussed. But for the sake of completeness, I think that the old Web 1.0 multipart/form-data technique should be supported, as was discussed in http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-690 In my comments there,mentioned that I implemented a solution in the PortletFaces Bridge. It's working quite nicely – no need for Servlet 3.0, no need for a filter. Everything works great. Making this work in a Servlet-based JSF like Mojarra should be a piece of cake.
          Hide
          tedgoddard added a comment -

          The approach to resolving this should be to provide additional APIs that make it possible to plug different transports into the JSF request/response cycle:

          • allow a partial response to be requested without a custom HTTP header
          • support new HTML5/XMLHttpRequest features that include file parts
          • expose JSF form serialization to String as JavaScript API
          • ensure that jsf.ajax.response can easily be called by external code (context and jsfResponse do not seem to be entirely public parameters)
          Show
          tedgoddard added a comment - The approach to resolving this should be to provide additional APIs that make it possible to plug different transports into the JSF request/response cycle: allow a partial response to be requested without a custom HTTP header support new HTML5/XMLHttpRequest features that include file parts expose JSF form serialization to String as JavaScript API ensure that jsf.ajax.response can easily be called by external code (context and jsfResponse do not seem to be entirely public parameters)
          Hide
          werpu12 added a comment - - edited

          Actually that is how we prototyped it for myfaces. We dont have an official api, but we have configuration options which allow to choose a certain transport type.

          So you can define jsf.ajax.request with additional myfaces:

          {transportType: "iframeRequest"}

          etc.. options to force the system into an iframe request.

          We also allow an auto transport option where the system changes from the default xhr level1 into iframe if a multipart file upload situation is detected.

          The problem with xhr level3 simply is or was the last time I looked at it that most browsers issued multipart requests without length attributes which rendered most fileupload libraries useless (and broke one of the two related specs in that area)
          so an auto fallback to xhr level3 is definitely given the state of affairs a no go.

          But as I see it xhr level3 is a good option if you can support it properly because it also allows some kind of progress notification so if this issue is started we also should opt for xhr level3 optionally.

          The http header issue was another one. Currently the jsf ajax cycle is determined over custom http header, which is a no go in an iframe scenario because you only can send parameters, this needs to be fixed (and I did an internal fallback in myfaces to fix this but this is currently an implementation detail.

          the jsf.ajax.response is another issue relatively unrelated, in myfaces we have some internal params which fix some internal issues, like how do you fix the issue of having an update and your original element is detached as well as its parent form. Those kind issues simply have to be taken care of in the official spec then I guess the jsf.ajax.response is really public.
          I guess mojarra has 1-2 of those extra bugfix params as well.
          But actually in case of myfaces I just got this bugreport in and it indeed is a bug in our impl because the call to the jsf.ajax.response should work without any extra params.

          Show
          werpu12 added a comment - - edited Actually that is how we prototyped it for myfaces. We dont have an official api, but we have configuration options which allow to choose a certain transport type. So you can define jsf.ajax.request with additional myfaces: {transportType: "iframeRequest"} etc.. options to force the system into an iframe request. We also allow an auto transport option where the system changes from the default xhr level1 into iframe if a multipart file upload situation is detected. The problem with xhr level3 simply is or was the last time I looked at it that most browsers issued multipart requests without length attributes which rendered most fileupload libraries useless (and broke one of the two related specs in that area) so an auto fallback to xhr level3 is definitely given the state of affairs a no go. But as I see it xhr level3 is a good option if you can support it properly because it also allows some kind of progress notification so if this issue is started we also should opt for xhr level3 optionally. The http header issue was another one. Currently the jsf ajax cycle is determined over custom http header, which is a no go in an iframe scenario because you only can send parameters, this needs to be fixed (and I did an internal fallback in myfaces to fix this but this is currently an implementation detail. the jsf.ajax.response is another issue relatively unrelated, in myfaces we have some internal params which fix some internal issues, like how do you fix the issue of having an update and your original element is detached as well as its parent form. Those kind issues simply have to be taken care of in the official spec then I guess the jsf.ajax.response is really public. I guess mojarra has 1-2 of those extra bugfix params as well. But actually in case of myfaces I just got this bugreport in and it indeed is a bug in our impl because the call to the jsf.ajax.response should work without any extra params.
          Hide
          Ed Burns added a comment -

          Bulk assign all of Sheetal's spec issues to me.

          Show
          Ed Burns added a comment - Bulk assign all of Sheetal's spec issues to me.
          Hide
          Ed Burns added a comment - - edited

          Neil committed his version of the work to https://svn.java.net/svn/mojarra~svn/branches/FILE_UPLOAD

          These are the files that differ from the state of the tree when he created that branch.

          These files were committed in r9162.

          Index: common/ant/dependencies.xml
          Index: jsf-api/doc/file-props.xml
          Index: jsf-api/doc/standard-html-renderkit-base.xml
          Index: jsf-api/doc/standard-html-renderkit.xml
          Index: jsf-api/src/main/java/javax/faces/component/UploadedFile.java
          Index: jsf-ri/conf/share/html_basic.taglib.xml
          Index: jsf-ri/src/main/java/com/sun/faces/context/ExternalContextImpl.java
          Index: jsf-ri/src/main/java/com/sun/faces/context/RequestParameterMapMultiPartImpl.java
          Index: jsf-ri/src/main/java/com/sun/faces/context/RequestParameterMapFactory.java
          Index: jsf-ri/src/main/java/com/sun/faces/context/RequestParameterValuesMapMultiPartImpl.java
          Index: jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/html/HtmlDecorator.java
          Index: jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/html/HtmlLibrary.java
          Index: jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/FileRenderer.java
          Index: jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/TextRenderer.java
          Index: jsf-ri/src/main/java/com/sun/faces/component/UploadedFileImpl.java
          Index: jsf-ri/src/main/resources/com/sun/faces/standard-html-renderkit-impl.xml

          Show
          Ed Burns added a comment - - edited Neil committed his version of the work to https://svn.java.net/svn/mojarra~svn/branches/FILE_UPLOAD These are the files that differ from the state of the tree when he created that branch. These files were committed in r9162. Index: common/ant/dependencies.xml Index: jsf-api/doc/file-props.xml Index: jsf-api/doc/standard-html-renderkit-base.xml Index: jsf-api/doc/standard-html-renderkit.xml Index: jsf-api/src/main/java/javax/faces/component/UploadedFile.java Index: jsf-ri/conf/share/html_basic.taglib.xml Index: jsf-ri/src/main/java/com/sun/faces/context/ExternalContextImpl.java Index: jsf-ri/src/main/java/com/sun/faces/context/RequestParameterMapMultiPartImpl.java Index: jsf-ri/src/main/java/com/sun/faces/context/RequestParameterMapFactory.java Index: jsf-ri/src/main/java/com/sun/faces/context/RequestParameterValuesMapMultiPartImpl.java Index: jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/html/HtmlDecorator.java Index: jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/html/HtmlLibrary.java Index: jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/FileRenderer.java Index: jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/TextRenderer.java Index: jsf-ri/src/main/java/com/sun/faces/component/UploadedFileImpl.java Index: jsf-ri/src/main/resources/com/sun/faces/standard-html-renderkit-impl.xml
          Hide
          Ed Burns added a comment -

          Notes from merging in Neil's work.

          Show
          Ed Burns added a comment - Notes from merging in Neil's work.
          Hide
          Ed Burns added a comment -

          In progress patch.

          Show
          Ed Burns added a comment - In progress patch.
          Hide
          Ed Burns added a comment -

          muellermi
          @edburns Will JSF's AJAX file upload offer functions to display progress? Or suport multi-file uploads?

          Show
          Ed Burns added a comment - muellermi @edburns Will JSF's AJAX file upload offer functions to display progress? Or suport multi-file uploads?
          Hide
          werpu12 added a comment -

          Progress is not possible with existing html means, XHR Level 2 in the long run will support it. Not sure if the spec can specifiy a progress event which if supported can be fired and if not does nothing except to go from 0 to 100, it would make sense. Same I think goes for multiple file uploads.
          (Cannot remember if the existing iframe method supports multiple file uploads)

          Show
          werpu12 added a comment - Progress is not possible with existing html means, XHR Level 2 in the long run will support it. Not sure if the spec can specifiy a progress event which if supported can be fired and if not does nothing except to go from 0 to 100, it would make sense. Same I think goes for multiple file uploads. (Cannot remember if the existing iframe method supports multiple file uploads)
          Hide
          Ed Burns added a comment -

          Move to Sprint 10, but at leas we have the non-Ajax portion committed.

          Show
          Ed Burns added a comment - Move to Sprint 10, but at leas we have the non-Ajax portion committed.
          Hide
          Ed Burns added a comment -

          Move to sprint 11

          Show
          Ed Burns added a comment - Move to sprint 11
          Hide
          robweaver added a comment -

          Just updated to 3.1.2 (Build 23) and the FileUpload on PrimeFaces broke (I think due to this issue).

          Upload widget acts as if the upload is working, but never hits the back end event handler.

          Reverting to 3.1 with no changes to WAR and the file upload works again.

          Would be glad to help diagnose this issue.

          Any target date for the fix, and is there a workaround ?

          Show
          robweaver added a comment - Just updated to 3.1.2 (Build 23) and the FileUpload on PrimeFaces broke (I think due to this issue). Upload widget acts as if the upload is working, but never hits the back end event handler. Reverting to 3.1 with no changes to WAR and the file upload works again. Would be glad to help diagnose this issue. Any target date for the fix, and is there a workaround ?
          Hide
          Ed Burns added a comment -

          Hello robweaver,

          Can I ask you please to file this in the GLASSFISH JIRA? I know some multipart upload changes were done in GlassFish 3.1.2 and t's quite possible this has nothing to do with Mojarra JSF implementation. At any rate, it certainly doesn't have anything to do with the spec.

          http://java.net/jira/browse/GLASSFISH

          Thanks,
          Ed

          Show
          Ed Burns added a comment - Hello robweaver, Can I ask you please to file this in the GLASSFISH JIRA? I know some multipart upload changes were done in GlassFish 3.1.2 and t's quite possible this has nothing to do with Mojarra JSF implementation. At any rate, it certainly doesn't have anything to do with the spec. http://java.net/jira/browse/GLASSFISH Thanks, Ed
          Hide
          robweaver added a comment -

          Thanks, I thought I was entering it on the GlassFish issue, sorry see http://java.net/jira/browse/GLASSFISH-18444 which appears to be my issue.

          Apologies for the incorrect entry.

          Show
          robweaver added a comment - Thanks, I thought I was entering it on the GlassFish issue, sorry see http://java.net/jira/browse/GLASSFISH-18444 which appears to be my issue. Apologies for the incorrect entry.
          Hide
          rogerk added a comment -

          There currently is a bug in the implementation - see: http://java.net/jira/browse/JAVASERVERFACES-2420. However, if the page author specifies a "value" attribute it should be rendered.

          Show
          rogerk added a comment - There currently is a bug in the implementation - see: http://java.net/jira/browse/JAVASERVERFACES-2420 . However, if the page author specifies a "value" attribute it should be rendered.
          Hide
          Ed Burns added a comment -

          Werner prepared this document prior to a 60 minute Google+ hangout we had today. We edited the document during the meeting.

          Show
          Ed Burns added a comment - Werner prepared this document prior to a 60 minute Google+ hangout we had today. We edited the document during the meeting.
          Show
          Ed Burns added a comment - See < http://tim-vm9.us.oracle.com:7070/hudson/job/trunk-test-glassfish-4_0/442/ >.
          Hide
          Ed Burns added a comment -

          Werner had some additional feedback.

          Show
          Ed Burns added a comment - Werner had some additional feedback.
          Hide
          arjan tijms added a comment -

          As JSF 2.2 went final, shouldn't this issue be closed?

          Show
          arjan tijms added a comment - As JSF 2.2 went final, shouldn't this issue be closed?
          Hide
          rogerk added a comment -

          Fixed for 2.2

          Show
          rogerk added a comment - Fixed for 2.2
          Hide
          jid1 added a comment -

          Did the "multiple" attribute make it into the spec?

          Show
          jid1 added a comment - Did the "multiple" attribute make it into the spec?
          Hide
          Ed Burns added a comment -

          Well, yes and no. I just tested it.

          Here's the yes part.

          You can say this:

          <html xmlns="http://www.w3.org/1999/xhtml"
                xmlns:ui="http://xmlns.jcp.org/jsf/facelets"
                xmlns:f="http://xmlns.jcp.org/jsf/core"
                xmlns:h="http://xmlns.jcp.org/jsf/html"
                xmlns:p="http://xmlns.jcp.org/jsf/passthrough">
              <h:head></h:head>
          
              <h:form id="form" enctype="multipart/form-data" prependId="false">
                  
                  <p><h:inputFile id="file" value="#{fileUploadBean.uploadedFile}" p:multiple="multiple"> 
                       <f:validator validatorId="FileValidator" />
                     </h:inputFile>
                  </p>
          ...
          

          and it renders correctly:

                  <p><input id="file" type="file" name="file" multiple="multiple" />
          

          but the no part is that each of the files in the multiple list is overwritten when the next one is processed.

          Show
          Ed Burns added a comment - Well, yes and no. I just tested it. Here's the yes part. You can say this: <html xmlns= "http: //www.w3.org/1999/xhtml" xmlns:ui= "http: //xmlns.jcp.org/jsf/facelets" xmlns:f= "http: //xmlns.jcp.org/jsf/core" xmlns:h= "http: //xmlns.jcp.org/jsf/html" xmlns:p= "http: //xmlns.jcp.org/jsf/passthrough" > <h:head></h:head> <h:form id= "form" enctype= "multipart/form-data" prependId= " false " > <p><h:inputFile id= "file" value= "#{fileUploadBean.uploadedFile}" p:multiple= "multiple" > <f:validator validatorId= "FileValidator" /> </h:inputFile> </p> ... and it renders correctly: <p><input id= "file" type= "file" name= "file" multiple= "multiple" /> but the no part is that each of the files in the multiple list is overwritten when the next one is processed.
          Hide
          Ed Burns added a comment -

          I have filed < https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1197 > to cover this. We'll get to it in 2.3.

          Show
          Ed Burns added a comment - I have filed < https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1197 > to cover this. We'll get to it in 2.3.

            People

            • Assignee:
              Ed Burns
              Reporter:
              werpu12
            • Votes:
              10 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1 week
                1w
                Remaining:
                Time Spent - 15 hours, 57 minutes Remaining Estimate - 6 days, 8 hours, 3 minutes
                6d 8h 3m
                Logged:
                Time Spent - 15 hours, 57 minutes Remaining Estimate - 6 days, 8 hours, 3 minutes
                15h 57m