Hmmmm.....
After more inspection, it looks like the parameter "has" to be set via
hivemind or some other means. This is because the incoming request needs to
be processed via the Servlet Request pipeline stuff, which knows nothing
about components and such...By the time the Upload component gets to it the
file has already been processed.
So, we can allow them to configure a global max file upload size, but not a
per Upload component one until a better solution is found.
Any objections to this?
On 3/21/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
>
> Agreed.
>
> The sizeMax naming was used because that's what commons-fileupload was
> doing. I agree that maxSize is a better name though.
>
>
> On 3/21/06, Paul Ferraro <[EMAIL PROTECTED]> wrote:
> >
> > I think the dev list is a probably more appropriate/efficient location
> > for the remainder of this discussion...
> > I agree with everything except "allowing it to accept it or not
> > depending on whether or not someone has manually configured it to be a
> > global value."
> >
> > I think we should scrap the _sizeMaxSet and
> > MultipartDecoder.setSizeMax() logic altogether.
> > I do agree with the first part though. Something like this perhaps?
> >
> > MultipartDecoderImpl:
> > public HttpServletRequest decode(HttpServletRequest request, Long
> > maxSize)
> > {
> > // ...
> > ServletFileUpload upload = createFileUpload(maxSize);
> > // ...
> > }
> >
> > private ServletFileUpload createFileUpload(Long maxSize)
> > {
> > // ...
> > upload.setMaxSize((maxSize != null) ? maxSize.longValue() :
> > _sizeMax);
> > // ...
> > }
> >
> > One last thing... can we rename sizeMax to maxSize?
> >
> > Thoughts?
> >
> > Paul
> >
> > Jesse Kuhnert (JIRA) wrote:
> > > [
> > http://issues.apache.org/jira/browse/TAPESTRY-368?page=comments#action_12371297]
> > >
> > > Jesse Kuhnert commented on TAPESTRY-368:
> > > ----------------------------------------
> > >
> > > Ok, a plausible solution....
> > >
> > > Change the Upload component's maxSize parameter to be an Integer
> > object, so that we can tell if it's actually been set or not, and don't give
> > it a default value. (Allow the MultipartDecoder service to handle that).
> > >
> > > Then, as previously mentioned, pass the parameter in to the Decoder
> > service, allowing it to accept it or not depending on whether or not someone
> > has manually configured it to be a global value.
> > >
> > > Does this sound workable?
> > >
> > >
> > >> Please add setMaxSize to MultipartDecoder
> > >> -----------------------------------------
> > >>
> > >> Key: TAPESTRY-368
> > >> URL: http://issues.apache.org/jira/browse/TAPESTRY-368
> > >> Project: Tapestry
> > >> Type: New Feature
> > >> Components: Framework
> > >> Versions: 4.0
> > >> Reporter: Gavin Mathias
> > >> Assignee: Jesse Kuhnert
> > >> Priority: Minor
> > >> Fix For: 4.0.1
> > >> Attachments: tap368.txt
> > >>
> > >> I use the Upload component to upload files to my application. Most of
> > those files are over the size limit of 10000000 hardcoded in
> > MultipartDecoderImpl. Please add setMaxSize(int _maxsize) to
> > MultipartDecoder so that I can write a custom Upload component that can do
> > this:
> > >> getDecoder().setMaxSize(30000000);
> > >> Even nicer would be a parameter in Tapestry's Upload.jwc that can be
> > used to set MaxSize.
> > >> I was doing this in Tapestry3.0.3 by calling:
> > >> DefaultMultipartDecoder.getSharedInstance ().setMaxSize(30000000);
> > >> in my custom component's page class.
> > >> Thanks and Best Regards,
> > >> Gavin
> > >>
> > >
> > >
> >
> >
> >
> >
>
>
> --
> Jesse Kuhnert
> Tacos/Tapestry, team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://opennotion.com
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://opennotion.com
