Подтвердить что ты не робот

Веб-приложение Spring MVC: контекст приложения запускается дважды

Я работаю над Spring MVC REST API. Все отлично работает, но это замечательно, но я заметил из журналов, что каждый раз, когда я перезапускаю приложение, приложение загружается дважды: один раз, когда tomcat загружает файл войны, а второй раз, когда веб-приложение открывается в первый раз клиент.

Я приведу несколько примеров:

Сразу после запуска tomcat:

Apr 11, 2013 10:14:35 AM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.32
Apr 11, 2013 10:14:36 AM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring root WebApplicationContext
2013-04-11 10:14:36 INFO  ContextLoader:273 - Root WebApplicationContext:     initialization started
2013-04-11 10:14:36 INFO  XmlWebApplicationContext:510 - Refreshing Root     WebApplicationContext: startup date [Thu Apr 11 10:14:36 EDT 2013]; root of context hierarchy
2013-04-11 10:14:36 INFO  XmlBeanDefinitionReader:315 - Loading XML bean definitions     from ServletContext resource [/WEB-INF/mvc-dispatcher-servlet.xml]
2013-04-11 10:14:36 INFO  XmlBeanDefinitionReader:315 - Loading XML bean definitions from class path resource [config-general.xml]
2013-04-11 10:14:37 INFO  XmlBeanDefinitionReader:315 - Loading XML bean definitions from class path resource [config-db.xml]
2013-04-11 10:14:37 INFO  XmlBeanDefinitionReader:315 - Loading XML bean definitions from class path resource [config-security.xml]
2013-04-11 10:14:37 INFO  SpringSecurityCoreVersion:33 - You are running with Spring Security Core 3.1.3.RELEASE
2013-04-11 10:14:37 INFO  SecurityNamespaceHandler:59 - Spring Security 'config' module version is 3.1.3.RELEASE

...

И вот на данный момент я делаю первый вызов API:

INFO: Initializing Spring FrameworkServlet 'mvc-dispatcher'
2013-04-11 10:15:25 INFO  DispatcherServlet:455 - FrameworkServlet 'mvc-dispatcher': initialization started
2013-04-11 10:15:25 INFO  XmlWebApplicationContext:510 - Refreshing WebApplicationContext for namespace 'mvc-dispatcher-servlet': startup date [Thu Apr 11     10:15:25 EDT 2013]; parent: Root WebApplicationContext
2013-04-11 10:15:25 INFO  XmlBeanDefinitionReader:315 - Loading XML bean definitions from ServletContext resource [/WEB-INF/mvc-dispatcher-servlet.xml]
2013-04-11 10:15:25 INFO  XmlBeanDefinitionReader:315 - Loading XML bean definitions from class path resource [config-general.xml]
2013-04-11 10:15:25 INFO  XmlBeanDefinitionReader:315 - Loading XML bean definitions from class path resource [config-db.xml]
2013-04-11 10:15:25 INFO  XmlBeanDefinitionReader:315 - Loading XML bean definitions from class path resource [config-security.xml]
2013-04-11 10:15:25 INFO  SecurityNamespaceHandler:59 - Spring Security 'config' module version is 3.1.3.RELEASE

Конечно, это не может быть нормальное поведение? Мой web.xml выглядит так:

http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd ">

<display-name>REST API</display-name>

<!-- Servlets -->
<servlet>
    <servlet-name>mvc-dispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>
<servlet-mapping>
    <servlet-name>mvc-dispatcher</servlet-name>
    <url-pattern>/</url-pattern>
</servlet-mapping>
<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/mvc-dispatcher-servlet.xml</param-value>
</context-param>

<!-- filters -->
<filter>
    <filter-name>httpMethodFilter</filter-name>
    <filter-class>org.springframework.web.filter.HiddenHttpMethodFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>httpMethodFilter</filter-name>
    <servlet-name>mvc-dispatcher</servlet-name>
</filter-mapping>
<filter>
    <filter-name>etagFilter</filter-name>
    <filter-class>org.springframework.web.filter.ShallowEtagHeaderFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>etagFilter</filter-name>
    <servlet-name>mvc-dispatcher</servlet-name>
</filter-mapping>
<filter>
    <filter-name>CompressingFilter</filter-name>
    <filter-class>com.planetj.servlet.filter.compression.CompressingFilter</filter-class>
    <init-param>
        <param-name>debug</param-name>
        <param-value>false</param-value>
    </init-param>
    <init-param>
        <param-name>statsEnabled</param-name>
        <param-value>false</param-value>
    </init-param>
</filter>
<filter-mapping>
    <filter-name>CompressingFilter</filter-name>
    <servlet-name>mvc-dispatcher</servlet-name>
</filter-mapping>
<filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>springSecurityFilterChain</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>



<!-- listeners -->
<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

4b9b3361

ОТВЕТЫ

Ответ 1

mvc-dispatcher загружает 2 раза, потому что именно так вы его определили

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/mvc-dispatcher-servlet.xml</param-value>
</context-param>

и в

<servlet>
    <servlet-name>mvc-dispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>
<servlet-mapping>
    <servlet-name>mvc-dispatcher</servlet-name>
    <url-pattern>/</url-pattern>
</servlet-mapping>

первый подход обычно используется для загрузки чего-то вроде "глобального" или "корневого" контекста, где вы можете поместить все компоненты/ресурсы, разделяемые несколькими контекстами сервлетов.

Второй подход обычно предназначен для загрузки определенного контекста сервлета. Как указывает первый ответ в этом сообщении, он использует соглашение об именах, чтобы найти конфигурационный файл mvc-dispatcher, поэтому вам не нужно явно определять его.

У вас есть все, что определено в mvc-dispatcher-servlet.xml? Если это так, вы можете удалить

<context-param>
  ..
</context-param>

в противном случае вы можете (что я рекомендую для будущей ремонтопригодности) разделить вашу конфигурацию на несколько файлов. Затем загрузите совместно используемые beans/resource в нечто вроде root-context.xml (через первый метод) и каждую конфигурацию сервлета под servletname-servlet.xml для каждого контекста сервлета.