一个标准的Spring Web应用程序(由Roo或“ Spring MVC Project”模板创建)使用ContextLoaderListener和创建一个web.xml DispatcherServlet。为什么他们不仅使用DispatcherServlet并使其加载完整的配置?
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完全删除。(我仍然将拥有不同的配置文件,但只有一个上下文。)
DispatcherServlet并ContextLoaderListener
有什么理由不删除ContextLoaderListener吗?
在你的情况下,没有,没有理由保留ContextLoaderListener和applicationContext.xml。如果你的应用程序仅在servlet的上下文中运行良好,那么坚持下去,那就简单了。
applicationContext.xml
是的,通常鼓励使用的模式是将非Web内容保留在webapp级别的上下文中,但这仅是一个较弱的约定。
使用webapp级上下文的唯一令人信服的理由是:
DelegatingFilterProxy
OpenEntityManagerInViewFilter
在将后台任务添加到servlet的上下文中时要特别小心,例如计划任务,JMS连接等。如果你忘记将其添加<load-on-startup>到web.xml,那么直到首次访问Servlet时这些任务才会启动。
<load-on-startup>
web.xml