Spring MVC的常见错误

标签: spring mvc 常见 | 发表时间:2014-07-24 11:43 | 作者:
出处:http://it.deepinmind.com

10年前我开始自己的职业生涯的时候,Struts还是市场上的主流标准。然而多年过后,我发现Spring MVC已经越来越流行了。对我而言这并不意外,因为它能和Spring容器无缝集成,同时它还提供了灵活性及扩展性。

从我迄今为止对Spring的经验来看,我发现有不少人在配置Spring的时候经常会犯一些常见的错误。跟使用Struts框架相比,这些错误要出现得更频繁一些。我猜想这可能是它在可用性和灵活性之间做出的权衡。不仅如此,Spring的文档中全是例子但缺少解释。为了填充这一空白,本文准备深入阐述三个大家常犯的错误。

在Servlet上下文定义文件中声明bean

我们都知道,Spring使用的是ContextLoaderListener来加载Spring的应用上下文(application context)。还有就是在声明 DispatcherServlet的时候,我们需要用"${servlet.name}-context.xml”的名字来创建servlet的上下文定义文件。你有想过为什么要这样吗?

应用上下文结构

并非所有的人都清楚,Spring应用上下文其实是分层的。我们看一下这个方法

   org.springframework.context.ApplicationContext.getParent()

它告诉我们,Spring应用上下文,其实是有父context的。那么,它是用来干什么的?

如果你下载一下源码,搜索一下方法引用,你会发现 Spring Application Context把双亲作为它的扩展。如果你不想读源码的话,我来给你演示一下BeanFactoryUtils.beansOfTypeIncludingAncestors()方法的一个用法 :

   if (lbf instanceof HierarchicalBeanFactory) {
    HierarchicalBeanFactory hbf = (HierarchicalBeanFactory) lbf;
    if (hbf.getParentBeanFactory() instanceof ListableBeanFactory) {
 Map parentResult = 
              beansOfTypeIncludingAncestors((ListableBeanFactory) hbf.getParentBeanFactory(), type);
 ...
    }
}
return result;
}

如果你看完整个方法,你会发现 Spring Application Context 会先在内部的上下文中查找bean,然后再去搜索父context。通过这个策略,Spring可以进行高效的反向广度优先搜索。

ContextLoaderListener

每个开发人员都应该了解这个类。它能帮忙你从预定义的上下文定义文件中加载Spring应用上下文。由于它实现了ServletContextListener接口,因此一旦WEB应用加载完毕,就会立即加载Spring的上下文。毋庸置疑,当加载包含@PostContruct注解或者批处理任务的Spring容器时,这个会非常有用。

反过来,任何在servlet上下文定义文件中定义的bean在servlet初始化前都不会构造。那servlet在何时会被初始化呢?这个是不确定的。最坏的情况下,你可能得等到用户第一次点击对应的servlet所映射的URL的时候,才会加载Spring上下文。

知道了以上这些信息,你认为你的bean声明应该放在哪里好呢?我觉得最佳的位置就是ContextLoaderListener所加载的上下文定义中了,没有其它。这里有个技巧就是将ApplicationContext作为servlet的一个属性进行存储,

   org.springframework.web.context.WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE   

然后,DispatcherServlet会从ServletContext中加载这个上下文,并把它赋值给上层的应用上下文。

   protected WebApplicationContext initWebApplicationContext() {
   WebApplicationContext rootContext =
      WebApplicationContextUtils.getWebApplicationContext(getServletContext());
   ...
}

由于它的这个行为 ,我强烈建议你只创建一个空的servlet应用上下文定义文件,将你的bean定义在父context中。这能避免当WEB应用加载时bean的重复创建,并能保证批处理作业能立即执行。

理论上说,将bean定义在servlet应用上下文定义文件中会使得bean对该servlet是唯一可见的。然而,在我8年的Spring使用经验来看,我发现这个特性几乎没有什么用处,除了用来定义 WEB service端点。

在ContextLoaderListener后面声明Log4jConfigListener

这是一个小BUG,不过如果你不注意的话,它会让你栽跟头。Log4jConfigListener是我最喜欢的解决-Dlog4j.configuration问题的一个方案,这样我们可以控制log4j的加载而不用改变服务器启动的进程。

很明显,这应该是你在web.xml中声明的第一个监听器。否则,你所声明的所有日志配置都将不会生效。

重复的bean定义

在早期的Spring中,开发人员更多的时间是花在了配置XML文件上,而不是Java类。对每一个新的bean,我们都需要声明它,然后自己将依赖注入,尽管这个做法很干净,整洁,但却非常痛苦。所以后续版本的Spring在可用性上进行了很大的提升这也不足为奇了。现在来说,开发人员只需要声明事务管理器,数据源,属性源,WEB服务endpoint,剩下的工作就交给组件扫描与自动织入来完成吧。

我喜欢这些新特性,但是权利越大,责任越大,否则的话,事情很快就会变得一团糟。XML文件中的组件扫描与bean声明是完全独立的。因此,在同一个bean容器内,如果bean被注解为组件扫描并且是手动声明的,就很有可能会出现相同类的不同bean。所幸的是,这种错误一般只发生在新手身上。

当我们需要集成一些嵌入式组件的时候,事情就变得复杂了。这个时候我们就需要一种策略来避免重复的bean声明。

上图展示了我们在日常工作中可能面临的真实案例。大多数时候,系统是由多个组件组成 的,一个组件服务于多个产品。每个应用和组件都有自己的bean。在这个例子中,怎么做才能最好地避免bean的重复声明?

下面是我个人提出的一个策略:

  • 确保每个组件都以一个独特的包名开头。这样当我们需要组件扫描的时候会更容易一些。
  • 不要让开发组件的团队将bean声明在组件内部(注解 VS XML声明)。负责将组件打包成最终产品的开发人员,他应该得去确保bean声明是唯一的。
  • 如果在组件内部有上下文定义文件,最好将它放在某个包底下,而不是classpath的根目录下。如果能给它分配一个专门的名字则更好。比如说,src/main/resources/spring-core/spring-core-context.xml总比src/main/resource/application-context.xml要好。想像一下如果你打包组件的时候发现同一个包底下存在相同的application-context.xml你会是什么心情。
  • 如果你已经将bean声明在一个context文件中了,就不要提供任何组件扫描的注解(@Component, @Service or @Repository)。
  • 不要在通用包上进行组件扫描。比如说,不要扫描org.springframework,扫描子包的话会更容易管理,比如说org.springframework.core, org.springframework.context, org.springframework.ui。

原创文章转载请注明出处: Spring MVC的常见错误

英文原文链接

相关 [spring mvc 常见] 推荐:

Spring MVC的常见错误

- - Java译站
10年前我开始自己的职业生涯的时候,Struts还是市场上的主流标准. 然而多年过后,我发现Spring MVC已经越来越流行了. 对我而言这并不意外,因为它能和Spring容器无缝集成,同时它还提供了灵活性及扩展性. 从我迄今为止对Spring的经验来看,我发现有不少人在配置Spring的时候经常会犯一些常见的错误.

Spring MVC 和 Struts2

- - CSDN博客架构设计推荐文章
Web层面的框架学习了三个Struts1和2,SpringMVC,那他们之间肯定存在一个优劣和适用的环境,Struts1和2的异同点我已经做过对比《 Struts1和Struts2》,这篇将对比下Struts2和SpringMVC的异同,下面数据基本来源于网络,本人是搜集整理所得,供大家参考. 一个项目使用什么样的技术,决定的因素很多,我所能想到的有:对系统的性能、开发的效率、团队学习的成本、业务场景等,下面尽量从这几个方面入手,来分析比较下他们之间存在的优劣.

Spring MVC 3 深入总结

- - 企业架构 - ITeye博客
大家好,Spring3 MVC是非常优秀的MVC框架,由其是在3.0版本发布后,现在有越来越多的团队选择了Spring3 MVC了. Spring3 MVC结构简单,应了那句话简单就是美,而且他强大不失灵活,性能也很优秀. 官方的下载网址是: http://www.springsource.org/download   (本文使用是的Spring 3.0.5版本).

Spring MVC 与 web开发

- - 码蜂笔记
项目组用了 Spring MVC 进行开发,觉得对里面的使用方式不是很满意,就想,如果是我来搭建开发环境,我会怎么做. 下面就是我的想法,只关注于 MVC 的 View 层. 现在基本上都是用 ajax 来调用后台接口,拿到 json格式的数据再展示,有的人直接返回数据,却没有考虑异常的情况,我觉得返回的报文里必须包含表示可能的异常信息的数据和业务响应数据.

spring mvc 异常处理(转)

- - 编程语言 - ITeye博客
链接:http://gaojiewyh.iteye.com/blog/1297746 (附源码). 链接:http://zywang.iteye.com/blog/983801 . 链接:http://www.cnblogs.com/xguo/p/3163519.html . 链接:http://fuliang.iteye.com/blog/947191 .

Spring MVC 入门实例

- - CSDN博客推荐文章
springmvc 框架围绕DispatcherServlet这个核心展开,DispatcherServlet是Spring MVC的总控制,它负责截获请求并将其分派给相应的处理器处理. SpringMVC框架包括注解驱动控制器、请求及响应的信息处理、视图解析、本地化解析、上传文件解析、异常处理以及表单标签绑定等内容.

Spring MVC Controller单例陷阱

- - 企业架构 - ITeye博客
Spring MVC Controller单例陷阱. 标签:Spring mvc. 原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明. Spring MVC Controller默认是单例的:. 1、这个不用废话了,单例不用每次都new,当然快了. 2、不需要实例会让很多人迷惑,因为spring mvc官方也没明确说不可以多例.

Spring MVC 中 HandlerInterceptorAdapter的使用

- - 企业架构 - ITeye博客
一般情况下,对来自浏览器的请求的拦截,是利用Filter实现的,这种方式可以实现Bean预处理、后处理. Spring MVC的拦截器不仅可实现Filter的所有功能,还可以更精确的控制拦截精度. Spring为我们提供了org.springframework.web.servlet.handler.HandlerInterceptorAdapter这个适配器,继承此类,可以非常方便的实现自己的拦截器.

Spring MVC防重复提交

- - 企业架构 - ITeye博客
如何在Spring MVC里面解决此问题(其它框架也一样,逻辑一样,思想一样,和具体框架没什么关系). 要解决重复提交,有很多办法,比如说在提交完成后redirect一下,也可以用本文提到的使用token的方法(我不使用redirect是因为那样解决不了ajax提交数据或者移动应用提交数据,另一个原因是现在比较通行的方法是使用token,像python里的django框架也是使用token来解决).

Spring MVC 3.2.4 ResponseBody 编码问题解决

- - 编程语言 - ITeye博客
首先请确保Spring版本为3.2.4. 问题1:使用@ResponseBody注解,返回对象类型时,如Map,中文字符,在客户端会显示为???. 解决办法:请检查依赖jar包,确保spring-context-support.jar的版本也是3.2.4,则可显示中文;. 问题2:使用@ResponseBody注解,返回String时,中文字符,在客户端会显示为???,并且contextType中会缺失encoding值,即为text/html但是,没有后面的encode.