ContextLoaderListener or not?

Question

一个标准的Spring Web应用程序（由Roo或“ Spring MVC Project”模板创建）使用ContextLoaderListener和创建一个web.xml DispatcherServlet。为什么他们不仅使用DispatcherServlet并使其加载完整的配置？

我知道应该使用ContextLoaderListener来加载与Web不相关的内容，而DispatcherServlet用于加载与Web相关的内容（控制器等）。这样就产生了两个上下文：父上下文和子上下文。

背景：

我用这种标准方式做了几年了。

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>classpath*:META-INF/spring/applicationContext*.xml</param-value>
</context-param>

<!-- Creates the Spring Container shared by all Servlets and Filters -->
<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<!-- Handles Spring requests -->
<servlet>
    <servlet-name>roo</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>WEB-INF/spring/webmvc-config.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

这通常会导致两个上下文及其之间的依存关系出现问题。过去，我总是能够找到解决方案，并且我强烈感觉这使软件结构/体系结构总是更好。但是现在我面对两种情况的问题。

-但是，这让我重新考虑了这两种上下文模式，我在问自己：为什么要陷入麻烦，为什么不将所有spring配置文件都加载其中一个DispatcherServlet并ContextLoaderListener完全删除。（我仍然将拥有不同的配置文件，但只有一个上下文。）

有什么理由不删除ContextLoaderListener吗？

Answer 1

在你的情况下，没有，没有理由保留ContextLoaderListener和applicationContext.xml。如果你的应用程序仅在servlet的上下文中运行良好，那么坚持下去，那就简单了。

是的，通常鼓励使用的模式是将非Web内容保留在webapp级别的上下文中，但这仅是一个较弱的约定。

使用webapp级上下文的唯一令人信服的理由是：

• 如果你有多个DispatcherServlet需要共享服务
• 如果你有旧版/非Spring servlet，需要访问Spring-wired服务
• 如果你的servlet过滤器，勾入Web应用程序级范围内（如Spring Security的DelegatingFilterProxy，OpenEntityManagerInViewFilter等等）
  这些都不适合你，因此不需要额外的复杂性。
  

在将后台任务添加到servlet的上下文中时要特别小心，例如计划任务，JMS连接等。如果你忘记将其添加<load-on-startup>到web.xml，那么直到首次访问Servlet时这些任务才会启动。