Utilisation de plusieurs fichiers de propriétés (via PropertyPlaceholderConfigurer) dans plusieurs projets / modules

Nous écrivons actuellement une application qui est divisée en plusieurs projets / modules. Par exemple, prenons les modules suivants:

• myApp-DAO
• myApp-jabber

Chaque module a son propre fichier xml de contexte Spring. Pour le module DAO, j'ai un PropertyPlaceholderConfigurer qui lit un fichier de propriétés avec les paramètres de connexion de base de données nécessaires. Dans le module jabber, j'ai également un PropertyPlaceHolderConfigurer pour les propriétés de connexion jabber.

Vient maintenant l'application principale qui comprend myApp-DAO et myApp-jabber. Il lit tous les fichiers de contexte et démarre un gros contexte Spring. Malheureusement, il semble qu'il ne puisse y avoir qu'un seul PropertyPlaceholderConfigurer par contexte, donc le module chargé en premier est capable de lire ses paramètres de connexion. L'autre lève une exception avec une erreur telle que "Impossible de résoudre l'espace réservé 'jabber.host'"

Je comprends en quelque sorte quel est le problème, mais je ne connais pas vraiment de solution - ni la meilleure pratique pour mon cas d'utilisation.

Comment configurer chaque module pour que chacun puisse charger son propre fichier de propriétés? En ce moment, j'ai déplacé le PropertyPlaceHolderConfigurer hors des fichiers de contexte séparés et les ai fusionnés dans le contexte de l'application principale (chargement de tous les fichiers de propriétés avec un seul PropertyPlaceHolderConfigurer). Cela craint, car maintenant, tous ceux qui utilisent le module dao doivent savoir qu'ils ont besoin d'un PropertyPlaceHolderConfigurer dans leur contexte ... les tests d'intégration dans le module dao échouent, etc.

Je suis curieux de connaître les solutions / idées de la communauté stackoverflow.

Si vous vous assurez que chaque espace réservé, dans chacun des contextes impliqués, ignore les clés insolubles, ces deux approches fonctionnent. Par exemple:

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

ou

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

Je sais que c'est une vieille question, mais la ignore-unresolvablepropriété ne fonctionnait pas pour moi et je ne savais pas pourquoi.

Le problème était que j'avais besoin d'une ressource externe (quelque chose comme location="file:${CATALINA_HOME}/conf/db-override.properties") et le ignore-unresolvable="true"ne fait pas le travail dans ce cas.

Ce qu'il faut faire pour ignorer une ressource externe manquante est:

ignore-resource-not-found="true"

Juste au cas où quelqu'un d'autre se heurterait à ça.

Vous pouvez avoir plusieurs <context:property-placeholder />éléments au lieu de déclarer explicitement plusieurs beans PropertiesPlaceholderConfigurer.

Le PropertiesPlaceholderConfigurerbean a une propriété alternative appelée "propertiesArray". Utilisez-la à la place de la propriété "properties" et configurez-la avec une <array>référence de propriété.

J'ai essayé la solution ci-dessous, cela fonctionne sur ma machine.

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

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

Si plusieurs éléments sont présents dans le contexte Spring, il existe quelques bonnes pratiques à suivre:

l'attribut order doit être spécifié pour fixer l'ordre dans lequel ceux-ci sont traités par Spring, tous les espaces réservés de propriété moins le dernier (ordre le plus élevé) devraient avoir ignore-unresolvable=”true”pour permettre au mécanisme de résolution de passer à d'autres dans le contexte sans lever d'exception

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