[
https://issues.apache.org/jira/browse/TRINIDAD-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Bohmann resolved TRINIDAD-2508.
-------------------------------------
Resolution: Fixed
Assignee: Dennis Kieselhorst (was: Bernd Bohmann)
I need a review of my changes and some more feedback/testing
> 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: Dennis Kieselhorst
> Fix For: 2.1.3-core
>
> Attachments: trinidad-2508.patch
>
>
> 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.15#6346)
