You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Andy Schwartz (JIRA)" <de...@myfaces.apache.org> on 2014/09/11 19:27:34 UTC

[jira] [Created] (TRINIDAD-2508) JSF 2.2 @MultipartConfig on FacesServlet breaks Trinidad file upload

Andy Schwartz created TRINIDAD-2508:
---------------------------------------

             Summary: JSF 2.2 @MultipartConfig on FacesServlet breaks Trinidad file upload
                 Key: TRINIDAD-2508
                 URL: https://issues.apache.org/jira/browse/TRINIDAD-2508
             Project: MyFaces Trinidad
          Issue Type: Bug
            Reporter: Andy Schwartz
            Assignee: Andy Schwartz


I have been testing Trinidad against JSF 2.2.  So far everything looks good with one exception:  Trinidad's file upload feature is broken.

I traced this down to a conflict between Java EE's multipart form support and Trinidad file upload.  Both Java EE and Trinidad are capable of processing multipart forms.  However, the multipart request input stream can only be read once, which means that only one layer gets to do this work.

Trinidad processes multipart forms in its FileUploadConfiguratorImpl, which is run from inside TrinidadFilterImpl.doFilter().  However, when running against JSF 2.2, the servlet engine (WLS in my case) is reading the request input stream before we get this far.  I found that this was happening in response to servlet request parameter lookups that are made by other Configurators.

The change in behavior from JSF 2.1 to JSF 2.2 is this:  prior to JSF 2.2 - and specifically, prior to the introduction of the @MultipartConfig annotation to FacesServlet, request parameter lookups that are made before the FileUploadConfiguratorImpl processes the multipart data would fail - ie. would return null without reading the request input stream.

After upgrading to JSF 2.2, the presence of the @MultipartConfig now tells the servlet engine that it is responsible for reading multipart form data.  Thus, request parameter lookups which previously behaved as no-ops are now causing the request input stream to be read.  As a result, by the time FileUploadConfiguratorImpl is invoked, there is no data left on the request input stream and Trinidad does not recognize that there are uploaded files.





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)