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)
