[ 
https://issues.apache.org/jira/browse/TRINIDAD-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962190#comment-15962190
 ] 

Bernd Bohmann commented on TRINIDAD-2508:
-----------------------------------------

Tested with:
myfaces 2.1.18 and jetty-plugin 7.6.9.v20130131

trinidad-example/trinidad-demo$ mvn -PjettyConfig jetty:run

and:

myfaces 2.2.12 and jetty-plugin 9.2.21.v20170120

trinidad-example/trinidad-demo$ mvn -PjettyConfig -Djsfversion=2.2 jetty:run


> 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)

Reply via email to