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/classes
katalogu, który jest normalnym miejscem, w którym kończą się pliki.
Odmiany obejmują dodatkowy spring
katalog (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.