You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Erik Gustavson <go...@gmail.com> on 2005/03/19 01:34:54 UTC

JBoss 4.0.1 & multipart [was Re: multipart forms & file upload]

So I haven't found a smoking gun just yet. I've gotten rid of tiles
but that didn't help. I've moved back to JDK 1.4.2 to double-check,
that did not change anything.

As far as I can tell, when I use a form with
enctype="multipart/form-data" under JBoss 4.0.1sp1 no ParameterMap
makes it through down into the LifeCycle. JBoss is using Tomcat/5.0.28
as its servlet engine. Regular forms work perfectly fine.

Does anyone have any ideas?


On Fri, 18 Mar 2005 11:53:18 -0800, Erik Gustavson <go...@gmail.com> wrote:
> Interesting....
> 
> So I'm debugging through the LifeCycleImpl and I noticed that when I'm
> using a multipart encoding type, the method
> "restoreView(facesContext)" always returns true on a submission, but
> if I don't use multipart, the same method returns false. This did not
> seem right to me, so I traced farther in:
> 
> I traced down into what restoreView is doing and the problem is
> occuring when it attempts to pull the viewRoot from
> JspStateManagerImpl.restoreTreeStructure() method. I'm using
> clientside state saving and there are no values being returned from
> the getRequestParameterMap() call. This of course break client-side
> state.
> 
> I switched over to server side state and I got a little farther, but
> because the requestParameter map is empty, I get bumped back to
> restore view again.
> 
> I'm continuing to look into it - somehow my request params are not
> available anymore when I'm using a multipart form. I will post my
> findings here as I learn more.
> 
> 
> On Fri, 18 Mar 2005 14:21:50 -0400, Sylvain Vieujot <sv...@apache.org> wrote:
> >  The ExtensionsFilter put the multipart requests in a
> > MultipartRequestWrapper.
> >  This wrapper  parses the request, and makes all the request parameters
> > available with the standard request.getParameter(..) method.
> >  So, standard and multipart requests can be handled the standard way by
> > every component.
> >  This means that it's not specific to the FileUpload component (even though
> > it's mostly useful for it).
> >
> >  Rest inline
> >
> >  On Fri, 2005-03-18 at 08:56 -0800, Erik Gustavson wrote:
> >  Yes, I should have mentioned that - my configuration is exactly the same.
> > Two things I noticed though - one, I tried debugging ExtensionsFilter - I
> > don't see it being called which I find odd. It gets initialized fine - I can
> > see it parsing the maxFileSize values, but it doesn't seem to handle
> > requests at all, which I find odd. Two, I'm not using the existing
> > FIleUpload component but rather making my own, so ExtensionsFilter shouldn't
> > cause any problems here - I've looked through the code for ExtensionsFilter
> > and the servletRequest wrapper and from what I can tell all that does for
> > multi-part form submissions is to pre-process the file data and store it
> > under an instance variable for easy retrieval by the FileUpload component.
> > Presumably the original multi-part content should still be available in the
> > request, right?
> >  No, as the request is wrapped in a MultipartRequestWrapper, you should now
> > get the parameters through request.getParameter( ... ) calls.
> >  You can't parse the request twice.
> >  What is bothering me is that nothing seems to get called on submission of
> > the request - the page simply reloads as if an error occurs very high up the
> > lifecycle, but I see nothing about this in logs, etc..... no decode methods
> > are invoked and I just see the encode methods get called again when the page
> > reloads... its very odd. This behavior is very specific to the presence of
> > the multi-part attribute in the form. I am using tiles and subviews - could
> > this have anything to do with it? I don't know, I never used tiles.
> >  Try in a standard JSF only form first.
> >
> >
> >
> >  -Erik On Thu, 17 Mar 2005 22:00:29 -0400, Sylvain Vieujot
> > <sv...@apache.org> wrote: > Did you configure the Extensions filter ? >
> > It handles the multipart forms. > > Here is an example of configuration :
> > <filter> > <filter-name>MyFacesExtensionsFilter</filter-name> >
> > <filter-class>org.apache.myfaces.component.html.util.ExtensionsFilter</filter-class>
> > > <init-param> <param-name>maxFileSize</param-name> >
> > <param-value>20m</param-value> <description>Set the size limit for >
> > uploaded files. Format: 10 - 10 bytes 10k - > 10 KB 10m - 10 MB 1g - 1 GB >
> > </description> </init-param> </filter> <filter-mapping> >
> > <filter-name>MyFacesExtensionsFilter</filter-name> >
> > <url-pattern>*.jsf</url-pattern> </filter-mapping> <filter-mapping> >
> > <filter-name>MyFacesExtensionsFilter</filter-name> >
> > <url-pattern>/faces/*</url-pattern> </filter-mapping> > Sylvain. > > > On
> > Thu, 2005-03-17 at 17:51 -0800, Erik Gustavson wrote: > So I'm working on a
> > custom FileUpload component for my application and I'm > running into an odd
> > problem where my decode method is not called if I set >
> > enctype="multipart/form-data" on the form. I've build a couple of other >
> > simple custom components already and they work fine. The one in question is
> > > very simple, no renderers, everything happens in the component itself, >
> > etc... If I remove the enctype, my decode method gets called. If I put it >
> > back in, my decode method is skipped - in fact, it appears that no >
> > processing what-so-ever occurs on submission of the form, I just end up >
> > right back on the view - I don't see any errors messages and stepping >
> > through the running app doesn't yield any clues (at least to me) I'm using >
> > the latest cut of code (1.0.9-beta), on JBoss 4.0.1 under JDK 1.5 Anyone >
> > have any pointers?
>