Как расположить файлы конфигурации контекста Spring так, чтобы они соответствовали зависимостям проекта? - PullRequest
Новая
       28

Как расположить файлы конфигурации контекста Spring так, чтобы они соответствовали зависимостям проекта?

3 голосов
/ 05 декабря 2011

У меня есть веб-приложение, которое зависит от двух других модулей.
Для простоты назовем их ServiceA модуль и ServiceB модуль.
Каждый из этих модулей имеет различные зависимости, а также общую зависимость от модуля Entities.
Каждый из вышеупомянутых модулей объявляет свой собственный контекстный файл Spring с информацией, относящейся к его области действия.
Сейчас я пытаюсь решить, как "связать" эти файлы конфигурации между проектами, и я немного озадачен.

Я знаю, что один из вариантов - просто объявить все «конечные» файлы (т.е. ServiceA, ServiceB и Entities) в web.xml веб-приложения (в параметре contextConfigLocation), но мне это не нравится вариант, особенно потому, что мой фактический вариант использования более сложный и имеет больше внутренних зависимостей, которые являются общими.

Моим первоначальным намерением было объявить в параметре contextConfigLocation только файлы конфигурации для ServiceA и ServiceB, поскольку это единственные проекты, от которых напрямую зависит веб-приложение (это легко увидеть, посмотрев в maven pom), а затем имейте ServiceA и ServiceB, чтобы включить эту директиву в их конфигурационный файл контекста весны <import resource="classpath:EntitiesContext.xml">. Преимущество этого подхода в том, что он согласуется с транзитивным подходом maven, в котором я объявляю, от чего я зависим, и если этот модуль зависит от чего-то, он перетаскивает его вместе с ним. Проблема этого подхода заключается в том, что я прочитал здесь , что все компоненты в модуле Entities будут созданы дважды (хотя в конце останется только один экземпляр), что является дорогостоящим и ненужным действием.

Мне бы очень хотелось услышать, как люди решают этот вариант использования, так как я не думаю, что я затронул какой-либо угловой случай.

Спасибо

Обновление Синтаксис, который я использовал в итоге, был classpath*:META-INF/*/*Context.xml, поскольку есть некоторые проблемы с синтаксисом, предложенным Томасом.
Для дополнительного чтения см. отчет об ошибке весны (который частично решил проблему) и сообщение в блоге относительно проблемы

Ответы [ 2 ]

2 голосов
/ 05 декабря 2011

Как насчет того, чтобы следовать некоторому соглашению об именах конфигурационных файлов и просто собирать все, что доступно на CLASSPATH? 

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
        classpath*:*Context.xml 
    </param-value>
</context-param>

Это решение предполагает, что очевидно, что все необходимые модули находятся в CLASSPATH, но также нет и ненужных модулей.

1 голос
/ 05 декабря 2011

Рассматривали ли вы использование конфигурации на основе аннотаций ?

Это должно позволить вам уменьшить размер конфигурации XML до нескольких строк.

В качестве альтернативы, использование верхнего уровня * конфигурации на основе Java позволит вам извлекать части, которые вы хотите, контролируемым образом (без необходимости поиска по всему пути к классам) и без каких-либо дублирующих компонентов или какого-либо XML файлы.

...