struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amit Sharma (JIRA)" <>
Subject [jira] Commented: (WW-3177) i18n not supported for file upload error messages
Date Wed, 08 Jul 2009 07:21:59 GMT


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:
>             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.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.

View raw message