java Spring MVC的常见错误

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的上下文。毋庸置疑,[email protected]器时,这个会非常有用。

反过来,任何在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的常见错误

Tagged: ,

Comments are closed.