[
https://issues.apache.org/struts/browse/WW-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46467#action_46467
]
Amit Sharma commented on WW-3177:
---------------------------------
As I analyzed the issue, I found out that it is occurring in the class
org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest at the line no.
140 of the distribution 2.1.6 inside the catch clause of the
parse(HttpServletRequest, String) method. Ideally, in this catch clause, I
should be verifying the type of exception. i.e. the FileUploadException that is
occurring is instance of
org.apache.commons.fileupload.FileUploadBase.FileSizeLimitExceededException or
org.apache.commons.fileupload.FileUploadBase.InvalidContentTypeException or
org.apache.commons.fileupload.FileUploadBase.SizeLimitExceededException etc.
And if it is use the corresponding struts property like
struts.messages.error.uploading or struts.messages.error.file.too.large from
the message bundle for the text of the error. But the issue here would be that
the interface org.apache.struts2.dispatcher.multipart.MultiPartRequest doesn't
have the getText() methods as in TextProvider.
I may enhance the parse method of the MultiPartRequest interface to declare a
throws clause for FileUploadException along with IOException but the struts
architects would vote against it cause 1. It breaks existing contract. 2.
Breaks existing applications 3. Declaring a throws clause of an exception in
module one(commons-fileupload) from within module two (struts2) is not
recommended 4. The FileUploadException is commons-fileupload specific and there
are other multi-part request implementation like Pell and cos
Another solution might be to declare static inner exception classes inside the
JakartaMultiPartRequest class. These classes would typically be extending the
IOException class so that any FileUploadException may be mapped to the
corresponding exception extending from IOException. and thus the calling code
becomes aware of the exception. But again, the caller has to check for the
corresponding type and manually inject the corresponding error message from the
key as action errors.
There might be other solutions to this as well but as of now I could think of
these only sitting from outside of the closer bunch of people that can take an
appropriate decision corresponding to this.
> i18n not supported for file upload error messages
> -------------------------------------------------
>
> Key: WW-3177
> URL: https://issues.apache.org/struts/browse/WW-3177
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7,
> 2.0.8, 2.0.9, 2.0.10, 2.0.11, 2.0.11.1, 2.0.11.2, 2.0.12, 2.0.13, 2.0.14,
> 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5, 2.1.6, 2.1.7
> Reporter: Amit Sharma
>
> I am troubleling with the FileUploadInterceptor in Struts2.
> I want to have printed my own messages on failure of the file upload which
> takes place in the interceptor. I am uploading files exceeding the set
> maximum size. Struts2 documentation talks about the properties
> struts.messages.error.uploading and struts.messages.error.file.too.large
> being the error message if the failure occurs or if the actual file size
> exceeds the configured maximum limit. But every time the message is something
> like <u>the request was rejected because its size (2352563) exceeds the
> configured maximum (2097152)</u>. This message comes from the
> FileUploadException that is thrown from with-in the common-fileupload class
> FileUploadBase. And In the class JakartaMultipartRequest where it is handled,
> the code in struts 2.1.6 simply adds this message in its collection of
> errors. and thus the error messages corresponding to the properties like
> <b>struts.messages.error.file.too.large</b>,
> <b>struts.messages.error.uploading</b> and
> <b>struts.messages.error.content.type.not.allowed</b> in various
> resource-bundles never gets applied.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
