Куда идут файлы конфигурации Spring bean в WAR-модуле Maven? - PullRequest
Новая
       22

Куда идут файлы конфигурации Spring bean в WAR-модуле Maven?

9 голосов
/ 13 сентября 2010

Я посмотрел на несколько примеров проектов и, похоже, не могу найти общий передовой опыт.Я видел конфигурационные файлы Spring bean, которые иногда попадают в каталог src/main/webapp/WEB-INF.Я видел это в сочетании с определением сервлета в web.xml следующим образом: 

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

Но я также видел конфигурационные файлы bean, включенные в web.xml верхний уровень - то есть внеServlet.Что это значит?Это для кросс-сервлетов?Иногда он находится в каталоге src/main/webapp/WEB-INF, а иногда в src/main/resources.Также я видел другие конфигурационные файлы bean-компонентов, определенные в модулях WAR, в которых почти все содержится в src/main/resources.

Я прочитал и перечитал документацию Spring, но единственное соглашение, которое я нашел, это то, что по умолчаниюфайл конфигурации контекста сервлета должен находиться в каталоге src/main/webapp/WEB-INF с именем {servlet-name}-servlet.xml.

Итак, каков лучший метод и почему?

Ответы [ 2 ]

12 голосов
/ 13 сентября 2010

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

Типичное веб-приложение Spring MVC содержит иерархию с двумя уровнями:

  • Контекст корневого веб-приложения загружен ContextLoaderListener. Расположение конфигурации этого контекста по умолчанию applicationContext.xml и может быть настроено с использованием <context-param> с именем contextConfigLocation, то есть на верхнем уровне web.xml. Этот контекст обычно содержит основную логику приложения.

  • Специфичный для сервлета контекст, загружаемый DispatcherServlet. Его конфигурационное местоположение по умолчанию <servletname>-servlet.xml и может быть настроено с использованием <init-param> с именем contextConfigLocation, то есть на уровне сервлета. Этот контекст обычно содержит материал, связанный с Spring MVC (контроллеры и т. Д.), Поскольку DispatcherServlet является частью Spring MVC.

Последний контекст является потомком первого.

Если веб-приложение не использует Spring MVC в качестве среды представления, оно не имеет DispatcherServlet и его контекста. Некоторые чрезвычайно простые образцы Spring MVC не имеют ContextLoaderListener и корневого контекста (однако вам нужен корневой контекст для функциональности кросс-сервлета, такой как Spring Security).

Файлы конфигурации веб-приложения по умолчанию находятся в корневой папке веб-приложения. Однако они могут быть помещены в classpath (то есть в src/main/webapp), в этом случае они доступны через префикс classpath:. Это может быть полезно, если вы собираетесь использовать некоторые из этих файлов в интеграционных тестах без контейнера сервлетов. Также префикс classpath: может быть полезен, когда вы хотите загрузить файл конфигурации из отдельного артефакта, то есть из файла JAR в /WEB-INF/lib.

2 голосов
/ 02 апреля 2012

Я думаю, что это хороший стиль - хранить код, его конфигурацию пружины в отдельном JAR, который включен в WAR, так что WAR в основном пуст, но для web.xml и тому подобного. Это избавляет вас от даже вопроса об этом. :-) Вы можете ссылаться на эти весенние конфигурации с префиксом classpath :.

Одним из преимуществ этого макета является то, что вы можете легко написать Unittests, которая создает полную конфигурацию Spring WAR в JAR. Я бы не рекомендовал использовать это для реальных тестов (хотя вы можете выполнять интеграционные тесты таким образом), но вы получаете быструю обратную связь, когда случайно нарушаете общую структуру файлов конфигурации без необходимости повторного развертывания приложения.

Если вам действительно нужно поместить конфигурационные файлы Spring в WAR (возможно, так как он также ссылается на bean-компоненты, реализованные в самой WAR), я бы также поместил их в обычный путь к ресурсам / WEB-INF / classes по причинам обсуждалось выше.

...