myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Schwartz (JIRA)" <...@myfaces.apache.org>
Subject [jira] [Created] (TRINIDAD-2508) JSF 2.2 @MultipartConfig on FacesServlet breaks Trinidad file upload
Date Thu, 11 Sep 2014 17:27:34 GMT
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)

Mime
View raw message