Używanie wielu plików właściwości (za pomocą PropertyPlaceholderConfigurer) w wielu projektach/modułach

Question

Obecnie piszemy aplikację, która jest podzielona na wiele projektów/modułów. Na przykład, weźmy następujące moduły:

• myApp-DAO
• myApp-jabber

Każdy moduł ma swój własny kontekst Wiosna pliku XML. Dla modułu DAO mam PropertyPlaceholderConfigurer, który odczytuje plik właściwości z wymaganymi parametrami połączenia db. W module Jabber mam również właściwość PropertyPlaceHolderConfigurer dla właściwości połączenia Jabber.

Teraz dostępna jest główna aplikacja, która obejmuje myApp-DAO i myApp-jabber. Czyta wszystkie pliki kontekstowe i rozpoczyna jeden duży kontekst wiosenny. Niestety wygląda na to, że może istnieć tylko jeden obiekt PropertyPlaceholderConfigurer dla każdego kontekstu, więc niezależnie od tego, który moduł zostanie wczytany jako pierwszy, jest w stanie odczytać jego parametry połączenia. Drugi rzuca wyjątek z błędem typu "Nie można rozwiązać symbolu zastępczego" jabber.host ""

W pewnym sensie rozumiem, na czym polega problem, ale tak naprawdę nie znam rozwiązania - ani najlepszej praktyki dla mojego przypadek użycia.

Jak skonfigurować każdy moduł, aby każdy mógł załadować swój własny plik właściwości? Właśnie teraz przeniosłem PropertyPlaceHolderConfigurer z oddzielnych plików kontekstowych i połączyłem je z kontekstem aplikacji głównej (ładowanie wszystkich plików właściwości za pomocą jednego PropertyPlaceHolderConfigurer). To jest do bani, ponieważ teraz każdy, kto używa modułu dao, musi wiedzieć, że potrzebuje w swoim kontekście obiektu PropertyPlaceHolderConfigurer .. również testy integracyjne w module fail dao itp.

Jestem ciekawy, aby usłyszeć o rozwiązaniach/pomysły ze społeczności stackoverflow ..

Answer 1

Jeśli upewnisz się, że każdy właściciel lokalizacji w każdym z kontekstów ignoruje nierozwiązywalne klucze, oba te podejścia działają. Na przykład:

<context:property-placeholder 
location="classpath:dao.properties, 
      classpath:services.properties, 
      classpath:user.properties" 
ignore-unresolvable="true"/> 

lub

<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> 
     <property name="locations"> 
      <list> 
       <value>classpath:dao.properties</value> 
       <value>classpath:services.properties</value> 
       <value>classpath:user.properties</value> 
      </list> 
     </property> 
     <property name="ignoreUnresolvablePlaceholders" value="true"/> 
    </bean> 

Answer 2

Fasola PropertiesPlaceholderConfigurer ma alternatywną właściwość o nazwie "propertiesArray". Użyj tej opcji zamiast właściwości "properties" i skonfiguruj ją za pomocą <array> odwołań do właściwości.

Answer 3

Możesz mieć wiele elementów <context:property-placeholder /> zamiast jawnie zadeklarować wiele fasoli PropertiesPlaceholderConfigurer.

Answer 4

wiem, że jest to stara sprawa, ale własność ignore-unresolvable nie działa na mnie, a ja nie wiem dlaczego.

Problem polegał na tym, że potrzebowałem zewnętrznego źródła (coś takiego jak location="file:${CATALINA_HOME}/conf/db-override.properties"), a ignore-unresolvable="true" nie spełnia tego zadania.

Co trzeba zrobić za ignorowanie brakujący zasób zewnętrzny jest:

ignore-resource-not-found="true" 

tylko w przypadku ktokolwiek inny wpadnie na to.

Answer 5

Próbowałem rozwiązanie poniżej, działa na moim komputerze.

<context:property-placeholder location="classpath*:connection.properties" ignore-unresolvable="true" order="1" /> 

<context:property-placeholder location="classpath*:general.properties" order="2"/> 

W przypadku wielu elementów są obecne w kontekście Wiosna, istnieje kilka najlepszych praktyk, które powinny być następuje:

atrybut

porządek musi być określona, ​​aby ustalić kolejność, w jakiej są one przetwarzane przez Spring wszystkie obiekty zastępcze pomniejszone o ostatnie jedno (najwyższe zamówienie) powinno mieć ignore-unresolvable=”true”, aby umożliwić mechanizmowi rozdzielczości przekazać innym w kontekście bez rzucając wyjątek

źródło: http://www.baeldung.com/2012/02/06/properties-with-spring/