ContextLoaderListener不是吗？ [英] ContextLoaderListener or not?

问题描述

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

我知道ContextLoaderListener应该被用来加载与web相关的东西，并且DispatcherServlet被用来加载web相关的东西（Controllers，...）。这个结果在两个上下文中：父母和孩子的上下文。

背景：

我在做这个标准的方式几年。

 < context-param> 
< param-name> contextConfigLocation< / param-name> 
< param-value> classpath *：META-INF / spring / applicationContext * .xml< / param-value> 
< / context-param> 
 
<！ - 创建所有Servlet和过滤器共享的Spring容器 - > 
< listener> 
< listener-class> org.springframework.web.context.ContextLoaderListener< / listener-class> 
< / listener> 
 
<！ - 处理Spring请求 - > 
< 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 ？

解决方案

在你的情况下，不，没有理由保留 ContextLoaderListener 和 applicationContext.xml 。如果你的应用程序只是在servlet的上下文中工作正常，那就更简单了。

是的，一般鼓励的模式是将非Web内容保存在webapp级别的上下文，但它只不过是一个弱势的惯例。

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

• 如果您有多个需要共享服务的 DispatcherServlet


• 如果您具有需要访问Spring有线服务的遗留/非Spring servlet


• 如果您有挂接到webapp级别上下文的servlet过滤器（例如Spring Security的 DelegatingFilterProxy ， OpenEntityManagerInViewFilter 等）

这些适用于您，所以额外的复杂性是无理的。

只要小心将后台任务添加到servlet的上下文中，如计划任务，JMS连接等。如果忘记添加< lo ad-on-startup> 到您的 web.xml ，那么在servlet的第一次访问之前，这些任务将不会被启动。 p>

A standard spring web application (created by Roo or "Spring MVC Project" Template) create a web.xml with ContextLoaderListener and DispatcherServlet. Why do they not only use the DispatcherServlet and make it to load the complete configuration?

I understand that the ContextLoaderListener should be used to load the stuff that is not web relevant and the DispatcherServlet is used to load the web relevant stuff (Controllers,...). And this result in two contexts: a parent and a child context.

Background:

I was doing it this standard way for several years.

<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>

This often caused problems with the two contexts and the dependencies between them. In the past I was always able to find a solution, and I have the strong feeling that this makes the software structure/architecture always better. But now I am facing a problem with the events of the both contexts.

-- However this makes my rethink this two context pattern, and I am asking myself: why should I bring myself into this trouble, why not loading all spring configuration files with one DispatcherServlet and removing the ContextLoaderListener completely. (I still will to have different configuration files, but only one context.)

Is there any reason not to remove the ContextLoaderListener?

解决方案

In your case, no, there's no reason to keep the ContextLoaderListener and applicationContext.xml. If your app works fine with just the servlet's context, that stick with that, it's simpler.

Yes, the generally-encouraged pattern is to keep non-web stuff in the webapp-level context, but it's nothing more than a weak convention.

The only compelling reasons to use the webapp-level context are:

• If you have multiple DispatcherServlet that need to share services
• If you have legacy/non-Spring servlets that need access to Spring-wired services
• If you have servlet filters that hook into the webapp-level context (e.g. Spring Security's DelegatingFilterProxy, OpenEntityManagerInViewFilter, etc)

None of these apply to you, so the extra complexity is unwarranted.

Just be careful when adding background tasks to the servlet's context, like scheduled tasks, JMS connections, etc. If you forget to add <load-on-startup> to your web.xml, then these tasks won't be started until the first access of the servlet.

这篇关于ContextLoaderListener不是吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！