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.
-Matthias
