[
https://issues.apache.org/jira/browse/TOMAHAWK-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879344#action_12879344
]
JZ commented on TOMAHAWK-1521:
------------------------------
After double checking, I had a typo in the ExtensionsFilter config for the
uploadMaxSize name which meant this was defaulting to the uploadMaxFileSize. I
understand from the above how this creates the non-recoverable error situation,
etc.
However, there that causes an unexpected (to me) situation.
That is, with the uploadMaxSize properly configured, the FileUploadIOException
is caught as expected @ ServletChacheFileSizeErrorsFileUpload:208. The
exception is cast, rethrown, and re-caught just below as a
FileUploadBase.FileSizeLimitExceededException and the request attributes are
set up. No problem.
However ... after handling, the FileItemIterator.hasNext() is called @ line
132, which causes a java.io.Exception ("stream closed") which is caught @ line
248, wrapped in a FileUploadException and handled at
MultipartRequestWrapper:176.
Is that, in fact, the intended behaviour? I now have error-level messages in
my log for a situation which was expected and could be handled gracefully.
If it's expected, I'm ok closing as invalid, with apologies for the confusion.
> ExtensionsFilter cacheFileSizeErrors Does Not Work As Advertised
> ----------------------------------------------------------------
>
> Key: TOMAHAWK-1521
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1521
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: File Upload
> Affects Versions: 1.1.9
> Environment: commons-fileupload-1.2.1
> Reporter: JZ
>
> With the extensions filter configured with cacheFileSizeErrors=true and
> uploadMaxFileSize=1M, I get the stacktrace below when uploading a file larger
> than 1M.
> This is NOT the expected stack trace.
> Note that ServletChacheFileSizeErrorsFileUpload is used.
> However, line 108 in that class has a comment which states that the line
> "throws a SizeLimitExceededException (wrapped by a FileUploadIOException) if
> the request is longer than the max size"
> That is not accurrate. The SizeLimitExceededException is NOT, in fact,
> wrapped.
> As a result, ServletChacheFileSizeErrorsFileUpload does not trap exceptions
> at the right level and the SizeLimitExceededException bubbles up to the
> MultipartRequestWrapper (which is the source of the WARN - level stack trace
> below).
> Basically, this behaviour renders the cacheFileSizeErrors property useless.
> Here's the stacktrace:
> 2010-06-15 15:07:57,234 WARN
> org.apache.myfaces.webapp.filter.MultipartRequestWrapper] -
> <SizeLimitExceededException while uploading file.> []
> org.apache.commons.fileupload.FileUploadBase$SizeLimitExceededException: the
> request was rejected because its size (3506126) exceeds the configured
> maximum (1048576)
> at
> org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.<init>(FileUploadBase.java:914)
> at
> org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:331)
> at
> org.apache.myfaces.webapp.filter.servlet.ServletChacheFileSizeErrorsFileUpload.parseRequestCatchingFileSizeErrors(ServletChacheFileSizeErrorsFileUpload.java:108)
> at
> org.apache.myfaces.webapp.filter.MultipartRequestWrapper.parseRequest(MultipartRequestWrapper.java:131)
> at
> org.apache.myfaces.webapp.filter.MultipartRequestWrapper.getParameter(MultipartRequestWrapper.java:274)
> at
> javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:158)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
