On 7/15/06, Ryan Wynn <[EMAIL PROTECTED]> wrote:
On 7/15/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > ... > > MultipartRequestWrapper wrapper = new MultipartRequestWrapper( > > (HttpServletRequest) request, resolveSize(strMaxSize, > > uploadMaxFileSize), resolveSize(strThreshold, > > uploadThresholdSize), strRepo); > > ... > HttpServletRequest in a Portlet container?Yeah, I know. Apparently, the ActionRequest in IBM's portlet container is a HttpServletRequest underneath. I do not get any errors for this. Not sure if this would throw class cast in other containers. But theoretically, since ActionRequest and PortletRequest are simply interfaces, the underlying object can be a HttpServletRequest. At least that's my understanding. > ... > > There were a few other small changes to avoid ClassCastExceptions but > > that's basically it. > > b/c of what? The other changes I made where to not set the portlet request flag if the ActionRequest was a multipart request. The reason for this was a temporary workaround to get around this in LifeCycleImpl 434 if (PortletUtil.isPortletRequest(facesContext)) 435 { 436 PortletRequest request = (PortletRequest)externalContext.getRequest(); 437 return request.getParameter(MyFacesGenericPortlet.VIEW_ID); 438 } 439 440 String viewId = externalContext.getRequestPathInfo(); //getPathInfo Since my externalContext.getRequest() is going to return a MultipartRequestWrapper, I would get a class cast exception here in the LifeCycleImpl because it expects PortletRequest. To work around, I removed the portlet request flag and returned multipartRequest.getParameter(MyFacesGenericPortlet.VIEW_ID) from the getRequestPathInfo() method in my overriden externalContext. I can put the portlet request flag back as long as LifeCycleImpl does not assume that getRequest() will return a PortletRequest. It just has to account for the fact that the request may be a MultipartRequestWrapper as well. The other sticking point that I needed to work around was this in MyFacesGenericPortlet. 387 ServletFacesContextImpl facesContext = (ServletFacesContextImpl)request. 388 getPortletSession(). 389 getAttribute(CURRENT_FACES_CONTEXT); It explicity wants a ServletFacesContextImpl but in my case I used my own flavor of FacesContext. So I just added an instanceof check to remove the explicit cast and cast appropriately. My overridden faces context also implements ReleaseableExternalContext so the rest of the method works. I think even if IBM's portlet container is the only one that implements ActionRequest as a HttpServletRequest it is worth taking a look at. Before the cast to HttpServletRequest is made a check could be inserted to see if it's possible. This would greatly improve the ease of use for file uploads in portlet containers that take this implementation approach. If this was incorporated in MyFacesGenericPortlet then the only change required to the portlet version of http://wiki.apache.org/myfaces/Setup_For_File_Uploads would be to place the maxsize, threshold, and repository parameters inside the portlet.xml instead of web.xml. Of course it would be great if the solution could apply generically to all portlet containers, but I think 1 is better than none. Just my 2 cents.
Actually, I just noticed this which I did not know even existed. http://jakarta.apache.org/commons/fileupload/apidocs/org/apache/commons/fileupload/portlet/PortletFileUpload.html Evidently, commons fileupload has had some support for this since 1.1. It looks like tomahawk may have only been using 1.0 http://myfaces.apache.org/tomahawk/dependencies.html
> > -Matthias >
