Or even better, it should rethrow the (wrapped) exception and let the
developer handle it.
In MultipartDecoderIml, instead of using an empty collection of FileItems
when the exception occurs, it could return the request without parsing it.
Would that work?
Issue created: https://issues.apache.org/jira/browse/TAP5-2136
I also got some more info:
The actual problem lies in commons-fileupload: the FileUploadException
occurs in ServletFileUpload#parseRequest, so no List is
returned. The "normal" form parameters would be in that list - no
list, no parame
I think I've seen this before but currently I don't remember precisely.
Please check if there's already a jira issue or fire a new if not.
On Mon, Jun 10, 2013 at 3:59 PM, Christian Köberl <
tapestry.christian.koeb...@gmail.com> wrote:
> I encountered a Problem with the "Upload" component since
I encountered a Problem with the "Upload" component since switching to
Tapestry 5.3 - the page activation context is lost, when the file size
exceeds UploadSymbols.FILESIZE_MAX.
The setup is quite simple - a page with a @PageActivationContext
property and a form with an Upload component in it.
T