当前位置: 首页 > 面试题库 >

ContextLoaderListener or not?

金理
2023-03-14
问题内容

一个标准的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吗?


问题答案:

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

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

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

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

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



 类似资料:

相关阅读

相关文章

相关问答