Порядок загрузки contextConfigLocation в web.xml проекта Spring Servlet
Предположим, что у меня есть проектSpring Java , и я пытаюсь настроить его как сервлет веб-сервера. Вот урезанная версия web.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>
Здесь важно отметить, что я указал два XML-файла для загрузки. Один из них является общим для всего моего приложения, в то время как другой специфичен для сервлета "my-servlet". Для установки только с одним сервлетом-сопоставлением это не имело бы смысла. Однако мой проект имеет несколько сопоставлений сервлетов и каждый из них имеет определенные настройки пружины для них.
Мой вопрос: какой contextConfigLocation будет загружен первым к весне? Будет ли это generalapplication context.xml или это будет specificApplicationContext.в XML? Что еще более важно, имеет ли значение порядок загрузки? Из моих усилий по отладке кажется очевидным, что это так, потому что я получаю различные ошибки, когда перемещаю некоторую независимую конфигурацию Spring из одного файла в другой.
NB: Является ли использование нескольких конфигураций пружин для нескольких сопоставлений сервлетов хорошей практикой, спорно. То же самое касается использования XML config вместо нового Java config. Но это не то, что я пытаюсь спросить Здесь. Давайте попробуем сосредоточиться на моем главном вопросе.
4 ответов:
generalApplicationContext.xmlэто тот, который будет загружен первым, потому что онApplicationContextзагружен с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фактически является дочерним контекстом выше загруженногоgeneralApplicationContext.xmlи это будет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>И да, порядок загрузки имеет значение. Потому что при загрузке родительского контекста все необходимые зависимости должны быть выполнены.
Следующая часть загружает контекстный файл и создаетApplicationContext . Этот контекст может, например, содержать такие компоненты, как транзакционные службы среднего уровня, объекты доступа к данным или другие объекты, которые можно использовать (и повторно использовать) в приложении. В каждом приложении будет один контекст приложения.
Другой контекст-этоWebApplicationContext , который являетсядочерним контекстом контекста приложения . Каждый<context-param> <param-name>contextConfigLocation</param-name> <param-value> /WEB-INF/spring/generalApplicationContext.xml </param-value> </context-param>DispatcherServletопределенное в Spring web-приложение будет иметь связанныйWebApplicationContext. Инициализация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>
Какой лучший способ на самом деле иметь журналы отладки весны сказать вам самому порядок. Если вы хотите войти в код, вы также можете взглянуть на
org.springframework.web.servlet.FrameworkServlet(DispatcherServletрасширяет этот класс) просто включите logger"org.springframework.web.servlet"для отладки уровня в предпочтительной среде ведения журналаВот как обычно выглядят журналы-ясно, что корневой контекст загружается первым и устанавливается в качестве родительского для контекста heirarchy - the далее загружается контекст сервлета.
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
Если у вас естьContextLoaderListener в вашем интернете.XML spring загрузит generalApplicationContext.xml первый. Это создаст бобы и предоставит им все сервлеты и фильтры. Этот xml должен иметь общие классы, бобы, которые используются в вашем приложении.
Более поздний контейнер spring загрузит specificApplicationContext.xml , потому что у вас есть загрузка при запуске в конфигурации сервлета. Если вы не указываете нагрузку при запуске, это specificApplicationContext.xml загрузится, когда первый запрос придет в ваше приложение с определенным url-шаблоном.
Как ваш вопрос, когда вы перемещаете springconfig из одной конфигурации в другую, это изменит доступность ресурсов приложения для контейнера. Если вы укажете бобы контроллера в generalApplicationContext.xml и вы не указываете их в specificApplicationContext.xml, то ваш DispatcherServlet не найдет сопоставления, так что вы увидите 404 ошибка.
Если вы хотите создать некоторые объекты bean по требованию, вы можете создать еще один сервлет-config для загрузки этого конкретного specificConfigurationFile2.xml и сопоставление с url-шаблоном.
Comments