Utilizzo di più file di proprietà (tramite PropertyPlaceholderConfigurer) in più progetti / moduli

Attualmente stiamo scrivendo un'applicazione che è suddivisa in più progetti / moduli. Ad esempio, prendiamo i seguenti moduli:

• myApp-DAO
• myApp-jabber

Ogni modulo ha il proprio file xml del contesto Spring. Per il modulo DAO ho un PropertyPlaceholderConfigurer che legge un file di proprietà con i parametri di connessione db necessari. Nel modulo jabber ho anche un PropertyPlaceHolderConfigurer per le proprietà di connessione jabber.

Ora arriva l'applicazione principale che include myApp-DAO e myApp-jabber. Legge tutti i file di contesto e avvia un grande contesto Spring. Sfortunatamente sembra che ci possa essere un solo PropertyPlaceholderConfigurer per contesto, quindi qualsiasi modulo viene caricato per primo è in grado di leggere i suoi parametri di connessione. L'altro genera un'eccezione con un errore del tipo "Impossibile risolvere il segnaposto" jabber.host ""

In un certo senso capisco qual è il problema, ma non conosco davvero una soluzione o la migliore pratica per il mio caso d'uso.

Come configurare ogni modulo in modo che ognuno possa caricare il proprio file di proprietà? In questo momento ho spostato PropertyPlaceHolderConfigurer fuori dai file di contesto separati e li ho uniti nel contesto dell'applicazione principale (caricando tutti i file di proprietà con un singolo PropertyPlaceHolderConfigurer). Questo però fa schifo, perché ora tutti coloro che usano il modulo dao devono sapere che hanno bisogno di un PropertyPlaceHolderConfigurer nel loro contesto .. anche i test di integrazione nel modulo dao falliscono ecc.

Sono curioso di conoscere soluzioni / idee dalla comunità di stackoverflow ..

Se ti assicuri che ogni segnaposto, in ciascuno dei contesti coinvolti, ignori le chiavi irrisolvibili, entrambi questi approcci funzionano. Per esempio:

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

o

    <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>

So che questa è una vecchia domanda, ma la ignore-unresolvableproprietà non funzionava per me e non sapevo perché.

Il problema era che avevo bisogno di una risorsa esterna (qualcosa di simile location="file:${CATALINA_HOME}/conf/db-override.properties") e ignore-unresolvable="true"in questo caso non funziona.

Quello che bisogna fare per ignorare una risorsa esterna mancante è:

ignore-resource-not-found="true"

Nel caso in cui qualcun altro si imbatta in questo.

È possibile avere più <context:property-placeholder />elementi invece di dichiarare esplicitamente più bean PropertiesPlaceholderConfigurer.

Il PropertiesPlaceholderConfigurerbean ha una proprietà alternativa chiamata "propertiesArray". Utilizzare questo invece della proprietà "proprietà" e configurarlo con un <array>riferimento di proprietà.

Ho provato la soluzione di seguito, funziona sulla mia macchina.

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

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

Nel caso in cui più elementi siano presenti nel contesto primaverile, ci sono alcune buone pratiche che dovrebbero essere seguite:

l'attributo order deve essere specificato per correggere l'ordine in cui vengono elaborati da Spring tutti i segnaposto delle proprietà meno l'ultimo (ordine più alto) dovrebbero ignore-unresolvable=”true”consentire al meccanismo di risoluzione di passare ad altri nel contesto senza generare un'eccezione

fonte: http://www.baeldung.com/2012/02/06/properties-with-spring/