[ 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 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
