Kolejność ładowania contextConfigLocation w sieci.xml projektu Spring Servlet

Załóżmy, że mam projekt Spring Java i próbuję go skonfigurować jako servlet serwera www. Oto okrojona wersja web.plik xml: 

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
        /WEB-INF/spring/generalApplicationContext.xml
    </param-value>
</context-param>

<servlet>
    <servlet-name>my-servlet</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/spring/specificApplicationContext.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>my-servlet</servlet-name>
    <url-pattern>/foo/*</url-pattern>
</servlet-mapping>

Najważniejsze jest to, że podałem dwa pliki XML do załadowania. Jeden jest ogólny dla całej mojej aplikacji, podczas gdy drugi jest specyficzny dla" my-servlet " servlet. W przypadku konfiguracji z jednym mapowaniem serwletów nie miałoby to sensu. Jednak mój projekt ma wiele mapowań serwletów i każdy z nich ma określone ustawienia sprężyny do nich.

Moje pytanie: który contextConfigLocation zostanie załadowany jako pierwszy do wiosny? Czy będzie to ogólny tekst wniosku.xml lub będzie to specyficzny applicationkontekst.xml? Co ważniejsze, czy kolejność załadunku ma znaczenie? Z moich wysiłków debugowania wydaje się oczywiste, że tak, ponieważ dostaję różne błędy, gdy przenoszę jakąś niezależną konfigurację sprężyny z jednego pliku do drugiego.

NB: To, czy używanie wielu konfiguracji sprężyn dla wielu mapowań serwletów jest dobrą praktyką, jest dyskusyjne. To samo dotyczy XML config zamiast nowego Java config. Ale nie o to próbuję zapytać. Spróbujmy skupić się na moim głównym pytaniu.

Author: ecbrodie, 2014-12-18
Source

4 answers

generalApplicationContext.xml jest Tym, który zostanie załadowany jako pierwszy, ponieważ jest to ApplicationContext załadowany ContextLoaderListener 

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

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
        /WEB-INF/spring/generalApplicationContext.xml
    </param-value>
</context-param>

specificApplicationContext.xml jest w rzeczywistości kontekstem potomnym powyższego załadowanego generalApplicationContext.xml i będzie to WebApplicationContext 

<servlet>
    <servlet-name>my-servlet</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/spring/specificApplicationContext.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>my-servlet</servlet-name>
    <url-pattern>/foo/*</url-pattern>
</servlet-mapping>

I tak kolejność załadunku ma znaczenie. Ponieważ gdy kontekst rodzica jest ładowany wszystkie wymagane zależności muszą być spełnione.

 19
Author: shazin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-12-18 05:45:41

Poniższa część ładuje plik kontekstowy i tworzy ApplicationContext . Kontekst ten może na przykład zawierać składniki, takie jak usługi transakcyjne warstwy średniej, obiekty dostępu do danych lub inne obiekty, które mogą być używane (i ponownie używane) w całej aplikacji. Będzie jeden kontekst aplikacji dla każdej aplikacji.

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
        /WEB-INF/spring/generalApplicationContext.xml
    </param-value>
</context-param>

Drugim kontekstem jest Webaplicationcontext , który jest kontekstem potomnym kontekstu aplikacji . Każdy DispatcherServlet zdefiniowana w aplikacji webowej Spring będzie miała skojarzoną WebApplicationContext. Inicjalizacja WebApplicationContext dzieje się tak: 

<servlet>
    <servlet-name>my-servlet</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/spring/specificApplicationContext.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

Po Więcej szczegółów patrz to i to

 8
Author: Ankur Singhal,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 10:31:30

Czy jest lepszy sposób na to, aby dzienniki debugowania Spring same powiedziały Ci kolejność. Jeśli chcesz dostać się do kodu Możesz również spojrzeć na org.springframework.web.servlet.FrameworkServlet (DispatcherServlet po prostu włącz logger "org.springframework.web.servlet", aby debugować poziom w preferowanym frameworku logowania

Oto jak zwykle wyglądałyby logi-oczywiście kontekst główny jest ładowany jako pierwszy i jest ustawiony jako rodzic dla heirarchii kontekstu - the kontekst servleta jest ładowany dalej.

INFO : org.springframework.beans.factory.xml.XmlBeanDefinitionReader - Loading XML bean definitions from ServletContext resource [/WEB-INF/spring/generalApplicatonContext.xml]
INFO : org.springframework.web.context.ContextLoader - Root WebApplicationContext: initialization completed in 256 ms
DEBUG: org.springframework.web.servlet.DispatcherServlet - Initializing servlet 'my-servlet'
INFO :Initializing Spring FrameworkServlet 'appServlet'
INFO : org.springframework.web.servlet.DispatcherServlet - FrameworkServlet 'my-servlet': initialization started
DEBUG: org.springframework.web.servlet.DispatcherServlet - Servlet with name 'appServlet' will try to create custom WebApplicationContext context of class 'org.springframework.web.context.support.XmlWebApplicationContext', using parent context [Root WebApplicationContext: startup date [Fri May 15 17:08:24 IST 2015]; root of context hierarchy
DEBUG: Loading XML bean definitions from ServletContext resource [/WEB-INF/spring/specificApplicationContext.xml
 6
Author: Shailendra,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-05-15 12:04:05

Jeśli posiadasz ContextLoaderListener w swojej sieci.XML spring załaduje General applicationcontext.XML pierwszy. To stworzy fasolki i dostarczy im wszystkie serwlety i filtry. Ten xml powinien mieć wspólne klasy, beans, które są używane w Twojej aplikacji.

Później kontener spring załaduje specificapplicationkontekst.xml , ponieważ w konfiguracji servlet ' a masz obciążenie przy starcie. Jeśli nie podasz obciążenia podczas uruchamiania, to specific applicationkontekst.xml zostanie załadowany, gdy pierwsze żądanie trafi do Twojej aplikacji z określonym wzorcem url.

Jako twoje pytanie, gdy przeniesiesz springconfig z jednej konfiguracji do drugiej, zmieni to dostępność zasobów aplikacji do kontenera. Jeśli określisz Kontroler beans w General applicationkontekst.xml i nie podajesz ich w specificapplicationkontekst.xml wtedy twój DispatcherServlet nie znajdzie mapowań, więc zobaczysz Błąd 404.

Jeśli chcesz utworzyć kilka obiektów bean na żądanie, możesz utworzyć jeszcze jeden servlet-config, aby załadować ten konkretny configurationfile2.xml i Mapuj do wzorca url.

 3
Author: Srinivas Rampelli,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-12-18 07:26:55