Java 为什么会出现错误;“文件太大”;是否在jsp中没有(正确)显示?

Java 为什么会出现错误;“文件太大”;是否在jsp中没有(正确)显示?,java,file-upload,struts2,validation,Java,File Upload,Struts2,Validation,我有一个应用程序,可以让你上传一些照片。我有一个带有表单的jsp页面,用于选择要上载的照片: subir foto.jsp ... <s:form action="SubirFoto" method="post" enctype="multipart/form-data" theme="bootstrap"> <s:file name="foto" label="Foto" /> <s:submit value="Upload" align="cente

我有一个应用程序,可以让你上传一些照片。我有一个带有表单的jsp页面,用于选择要上载的照片:

subir foto.jsp

...
<s:form action="SubirFoto" method="post" enctype="multipart/form-data" theme="bootstrap">
   <s:file name="foto" label="Foto" />
   <s:submit value="Upload" align="center" />
</s:form>
...
问题是,如果我尝试上传大于2MB的图像,应用程序会将我重定向到subir foto.jsp,但不会在jsp页面中出现任何错误

我做了一些实验,如果我在上传大照片时将
放在subir-foto.jsp中,会出现以下情况:

the request was rejected because its size (17224595) exceeds the configured maximum (2097152)
如您所见,这不是我在
global.properties
中定义的错误


为什么这两个不同的错误不是字段错误?这是引导程序插件的问题吗?还是一只Struts2的虫子?我做错什么了吗?感谢您提供的任何帮助。

我在Google中搜索了更多信息,发现了一个解释错误的博客(该博客条目来自2008年,我使用的是Struts 2.3.4):

我总结如何解决我的问题。问题是消息
请求被拒绝,因为它的大小…
是在Struts2类之一中硬编码的

对于这个问题,至少有三种解决方案(所有这些方案都是令人头痛的):一种是重新实现
org.apache.struts2.dispatcher.multipart.MultiPartRequest
class;第二个是重新实现org.apache.struts2.interceptor.FileUploadInterceptor类

第三个是在FileUpload类中放置一个
validate
方法

@Override
public void validate() {
    boolean error = false;

    Collection<?> tmp = getActionErrors();

    for (Object o : tmp) {
        if (o.toString().contains(
                "the request was rejected because its size")) {

            if (!error) {
                addFieldError("foto",
                        "El tamaño de la foto es muy grande (Máximo: 2MB)");
                error = true;
            }
        }
    }

}
@覆盖
public void validate(){
布尔错误=假;
集合tmp=getActionErrors();
用于(对象o:tmp){
如果(o.toString())包含(
“请求被拒绝,因为其大小”)){
如果(!错误){
addFieldError(“foto”,
“厄尔塔马诺·德拉福托·穆伊·格兰德(Máximo:2MB)”;
错误=真;
}
}
}
}
无论如何,我仍然无法理解为什么我定义的消息不起作用,因为在我搜索的所有站点中,都告诉我覆盖
struts.messages.error.file.too.large
,或者为什么这两个错误都是不同类型的错误(字段错误和操作错误)


谢谢大家的时间。

我在谷歌搜索了更多信息,发现了一个解释错误的博客(该博客是2008年的,我使用的是Struts 2.3.4):

我总结如何解决我的问题。问题是消息
请求被拒绝,因为它的大小…
是在Struts2类之一中硬编码的

对于这个问题,至少有三种解决方案(所有这些方案都是令人头痛的):一种是重新实现
org.apache.struts2.dispatcher.multipart.MultiPartRequest
class;第二个是重新实现org.apache.struts2.interceptor.FileUploadInterceptor类

第三个是在FileUpload类中放置一个
validate
方法

@Override
public void validate() {
    boolean error = false;

    Collection<?> tmp = getActionErrors();

    for (Object o : tmp) {
        if (o.toString().contains(
                "the request was rejected because its size")) {

            if (!error) {
                addFieldError("foto",
                        "El tamaño de la foto es muy grande (Máximo: 2MB)");
                error = true;
            }
        }
    }

}
@覆盖
public void validate(){
布尔错误=假;
集合tmp=getActionErrors();
用于(对象o:tmp){
如果(o.toString())包含(
“请求被拒绝,因为其大小”)){
如果(!错误){
addFieldError(“foto”,
“厄尔塔马诺·德拉福托·穆伊·格兰德(Máximo:2MB)”;
错误=真;
}
}
}
}
无论如何,我仍然无法理解为什么我定义的消息不起作用,因为在我搜索的所有站点中,都告诉我覆盖
struts.messages.error.file.too.large
,或者为什么这两个错误都是不同类型的错误(字段错误和操作错误)


感谢大家的支持。

首先,如果您试图上载的文件超过为struts.multipart.maxSize指定的文件大小,则会出现此错误

有一个非常简单的解决方案: 在struts.xml中,增加struts.multipart.maxSize的文件大小值

  <constant name="struts.multipart.maxSize" value="50777216000" />
  <param name="maximumSize">15728640</param>

15728640
使param name=“maximumSize”值小于struts.multipart.maxSize值,

与上述情况一样,除非您超过struts.multipart.maxSize限制,否则您将在global.properties中定义自定义错误。因此,请尝试将struts.multipart.maxSize值保持在某个较高的范围。

首先,如果您试图上载的文件超过为struts.multipart.maxSize指定的文件大小,则会出现此错误

有一个非常简单的解决方案: 在struts.xml中,增加struts.multipart.maxSize的文件大小值

  <constant name="struts.multipart.maxSize" value="50777216000" />
  <param name="maximumSize">15728640</param>

15728640
使param name=“maximumSize”值小于struts.multipart.maxSize值,

与上述情况一样,您将在global.properties中定义自定义错误,除非您超过struts.multipart.maxSize限制。因此,请尝试将struts.multipart.maxSize值保持在某个较高的范围。

global.properties是否注册为自定义i18n资源?e、 例如,这是否在struts.xml(或struts.properties)中):
?是的,我在struts.xml中有一行
是作为自定义i18n资源注册的global.properties?e、 例如,这是否在struts.xml(或struts.properties)中):
?是的,我在struts.xml中有一行
+1很好的发现。没有一个解决方案特别好。作为操作错误传递异常消息的方法将导致国际化问题。+1很好的发现。没有一个解决方案特别好。作为操作错误传递异常消息的方法将导致国际化问题。