Gdzie umieścić plik konfiguracyjny Spring?


18

Chcę zintegrować framework Spring w moim projekcie, szczególnie po stronie serwera.

Nie chcę więc umieszczać go w folderze pliku wojny WEB-INF.

Czy powinienem umieścić plik applicationContext.xml w każdej warstwie (oznacza to, że każdy projekt jest podzielony na odrębne projekty? (Usługi, Domena i DAO)

Jaka jest dobra praktyka?


Odpowiedzi:


25

Struktura plików Maven może w tym pomóc

Zasadniczo pliki konfiguracyjne Spring (które mogą mieć dowolną nazwę, nie tylko ogólną applicationContext.xml) są traktowane jako zasoby ścieżki klas i zapisywane pod nimi src/main/resources. Podczas procesu kompilacji są one następnie kopiowane do WEB-INF/classeskatalogu, który jest normalnym miejscem, w którym kończą się pliki.

Odmiany obejmują dodatkowy springkatalog (np. src/main/resources/spring) W celu oddzielenia kontekstów Spring od innych zasobów dedykowanych platformom aplikacji. Możesz podzielić konteksty aplikacji na dedykowane warstwy, takie jak:

example-servlet.xml
example-data.xml
example-security.xml

i tak dalej.

Co z różnymi środowiskami, takimi jak programowanie / testowanie / produkcja?

Zazwyczaj konfiguracja Spring powinna pobierać konfigurację środowiska ze swojego środowiska. Zwykle oznacza to użycie JNDI, JDBC, zmiennych środowiskowych lub plików właściwości zewnętrznych w celu zapewnienia niezbędnej konfiguracji. Podaję je w kolejności preferencji, ponieważ JNDI jest ogólnie łatwiejszy do administrowania niż zewnętrzne pliki właściwości w kontrolowanym klastrze produkcyjnym.

W przypadku testów integracyjnych może być konieczne użycie pliku konfiguracyjnego Spring „tylko do testu”. Zawierałoby to specjalne konteksty korzystające z testowanych komponentów bean lub konfiguracji. Będą one obecne pod src / test / resources i mogą mieć test-prefiks, aby upewnić się, że programiści są świadomi swojego celu. Typowym zastosowaniem byłoby dostarczenie źródła danych innego niż JNDI, być może ukierunkowanego na bazę danych HSQLDB podczas automatycznych testów kompilacji i można by do nich odwoływać się w przypadku testowym.

Zasadniczo jednak większość plików kontekstu Spring nie powinna wymagać specjalnej modyfikacji podczas przechodzenia między warstwami. Powinno być tak, że ten sam artefakt kompilacji (np. Plik WAR) jest używany w dev / test / production tylko z różnymi poświadczeniami.


2

Czy Twój projekt jest podzielony na moduły Maven? Jeśli tak, możesz dodać dodatkowy moduł tylko do plików konfiguracyjnych. Nazwijmy to config-module

config-module
      |
      |--> src\main\resources\config\spring\applicationContex.xml
      |--> src\main\resources\config\properties\application.properties
      |--> pom.xml

Taka konfiguracja jest sugestią. Skonfiguruj swój własny zestaw plików Spakuj go jak plik JAR i dodaj ten moduł jako zależność dowolnego innego modułu (sieć, lib, inny słoik).

Będziesz miał dostęp do zasobów modułu konfiguracji (xml, właściwości itp.), Ponieważ znajdują się one w ścieżce klasy.

moduł pom

<dependency>
    <groupId>com.myproject.group</groupId>
    <artifactId>config-module</artifactId>
</dependency>

Następnie użyj instrukcji importu z zewnętrznych plików kontekstowych Spring. Na przykład

<import resource="classpath*:com/package/subpackage/**/config/applicationContext.xml" />

To był świetny pomysł! Pozwoliłem sobie dodać trochę więcej, ponieważ twój przykładowy „zasób importu” nie działał dla mnie ...... Nadal uczę się „filtrowania” instrukcji importu (na podstawie pełnej nazwy pakietu) ... i nie pracowałem nad tym czkawką (dla przyszłych czytelników), aby odwrócić uwagę od tego wspaniałego pomysłu i odpowiedzi. Dzięki Laiv!
granadaCoder

Jednym z powodów niepowodzenia importu „co moim zdaniem powinno działać” jest ten błąd: github.com/spring-projects/spring-framework/issues/16017
granadaCoder
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.