I've been looking on the server side of things in RF5 and got kinda stuck there. I think the first one might be better since it is already a jQuery widget and the layout looks similar to what we're aiming for. Posted by forums Original post: https://community.jboss.org/message/857306#857306

ad) new widget we might want to do more rigorous search for alternative widgets. Let's collect requirements here: * drag-drop * progress indication * file size limits * rejection per file / mime-type (practically all things original widget had, just client-side) ----- ad) server-side implementation: good thing: client-side impl should completely avoid a need for heavyweight server-side impl bad thing: we won't be able to get rid of server-side impl /wrt processing in Servlets < 3.0 (such as 2.5). In fact, when we would limit ourselves to Servlets 3.0, the code is almost done (JSF 2.2 already implemented leverages it). But as JSF impls adopts most of the code for multipart/form-data request processing from Servlets 3.0, we can use the same path. ~ Lukas On Wed, Feb 12, 2014 at 12:24 PM, Michal Petrov < richfaces-dev(a)lists.jboss.org&gt; wrote:

We need to check all the criteria that file upload defines on both, server-side and client-side. Otherwise an "attacker" could bypass the criteria by modifying client-side code. On Thu, Feb 13, 2014 at 3:14 PM, Michal Petrov < richfaces-dev(a)lists.jboss.org&gt; wrote:

As Michal mentioned on the team meeting, we are not able to hook into XMLHttpRequest object that we need to make client-side progress tracking work. We did a bit of research with Brian yesteday and found out that there is no other library that would do what we want to achieve, so we can't really get inspired elsewhere. Note: the only such implementation is PrimeFaces but they don't use standard JSF AJAX (jsf.ajax.request function), they use jQuery.ajax If we look into implementation of jsf.js, XMLHttpRequest (XHR) is not really exposed anywhere, not even on onevent('begin') [1]. I believe it would be significant improvement to expose XHR instance used to drive given JSF AJAX request here, that's why I will fill JAVASERVERFACES (and MyFaces) issue Fortunately, there is a way how to hook into XHR instance itself - it is possible to intercept XHR.open method [2] by overriding its declaration. That's also the approach that we use in Graphene [3] (the impl there is actually more powerful than we need here). Even though, Graphene implementation is proven to work cross-browser: * IE8+ (IE7 and less is not worth the trouble) * Firefox, Chrome, Safari * Opera support unknown The idea is that we can: 1. override a XHR.open method just before jsf.ajax.request 2. wait for call to XHR.open and store reference to the invoked XHR instance 3. override a XHR.open method back just after jsf.ajax.request method These steps should be performed in a try {} catch {} block and if we do not succeed to obtain XHR instance this way, we should perform fallback to show progress bar that reflects "uploading" and "upload completed" states. There are two possible places for overriding: 1. richfaces.js intercepts calls to jsf.ajax.request already [5] 2. in fileupload.js [6] - note: I'm not sure whether we should do submitForm here, we may use RichFaces.ajax / jsf.ajax.request ~ Lukas [1] https://github.com/jboss/mohttp://stackoverflow.com/questions/629671/how-... [2] http://stackoverflow.com/questions/629671/how-can-i-intercept-xmlhttprequ... [3] https://github.com/arquillian/arquillian-graphene/blob/master/impl/src/ma... [4] http://www.w3schools.com/browsers/browsers_explorer.asp [5] https://github.com/richfaces/richfaces/blob/master/framework/src/main/res... [6] https://github.com/richfaces/richfaces/blob/master/framework/src/main/res... On Thu, Feb 13, 2014 at 3:55 PM, Lukáš Fryč <lukas.fryc(a)gmail.com&gt; wrote:

Well, it's not a Mojarra issue. The issue is with Undertow (http://undertow.io/) (the web server used by WildFly). When the request is sent on server (HttpServletRequestImpl) we're wrapping it in MultiPartRequest30, after that the request parameters cannot be reached. But for some reason it is working if I access the parameters before the request is wrapped. from FileUploadFacesContextFactory: {code:modifiedtitle=true|jivemacro_uid=_13942091424358239|class=jive_text_macro jive_macro_code _jivemacro_uid_13942091424358239} if (httpRequest.getContentType() != null && httpRequest.getContentType().startsWith("multipart/")) {     String uid = getParameterValueFromQueryString(httpRequest.getQueryString(), UID_KEY);     Enumeration<String> e = httpRequest.getParameterNames();     // without this line the parameters are inaccessible     if (uid != null) {         long contentLength = Long.parseLong(httpRequest.getHeader("Content-Length"));         …                             HttpServletRequest wrappedRequest;         if (ServletVersion.getCurrent().isCompliantWith(ServletVersion.SERVLET_3_0)) {             wrappedRequest = wrapMultipartRequestServlet30((ServletContext) context, httpRequest, uid,                              contentLength, progressControl);         } else {             wrappedRequest = wrapMultipartRequestServlet25((ServletContext) context, httpRequest,                              uid, contentLength, progressControl);         }     /*     wrappedRequest.getParameter("javax.faces.ViewState")     returns null unless the getParameterNames() method was called     */     } } {code} I'm not yet sure about the root of the issue but there seems to be a check for files being sent in the request which is why it only seems to affect fileUpload (that and I don't think we're wrapping the requests anywhere else). Posted by forums Original post: https://community.jboss.org/message/861277#861277

I've ran into an issue regarding the servlet versions. With the update we're adding support for Servlet 3.0 which makes processing the requests easier. However while we can detect what version the server supports we can't detect the actual version that is used and we cannot treat 2.5 as 3.0. This isn't an issue on WildFly which uses Servlet 3.0 by default but for example EAP 6.1 uses 2.5 by default (even though it supports 3.0). We have two options - either configure the servlet for 3.0 in web.xml: {code:jivemacro_uid=_14005078970557820|class=jive_text_macro jive_macro_code _jivemacro_uid_14005078970557820} <servlet>     <servlet-name>Faces Servlet</servlet-name>     <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>     <load-on-startup>1</load-on-startup>     <multipart-config>         <max-file-size>20848820</max-file-size>         <max-request-size>418018841</max-request-size>         <file-size-threshold>1048576</file-size-threshold>     </multipart-config> </servlet> {code} so we'll have to update all projects that make use of fileUpload. (I have to check what's the minimal necessary configuration). Or find a way to properly determine what servlet version we're dealing with. Posted by forums Original post: https://community.jboss.org/message/874222#874222