Nous sommes en train de rédiger une application divisée en plusieurs projets/modules. Par exemple, prenons les modules suivants:
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 à la 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 inclut myApp-DAO et myApp-Jabber. Il lit tous les fichiers de contexte et commence un grand contexte Spring. Malheureusement, il semble qu'il ne puisse y avoir qu'un seul PropertyPlaceholderConfigurer par contexte. Ainsi, le module chargé en premier est capable de lire ses paramètres de connexion. L'autre lève une exception avec une erreur du type "Impossible de résoudre le paramètre fictif 'Jabber.Host'"
Je comprends un peu le problème, mais je ne connais pas vraiment de solution - ni de meilleure pratique pour mon cas d'utilisation.
Comment pourrais-je configurer chaque module pour que chacun puisse charger son propre fichier de propriétés? À l'heure actuelle, j'ai déplacé le PropertyPlaceHolderConfigurer des fichiers de contexte distincts 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 cependant, car à présent 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 d'entendre parler de solutions/idées de la communauté de stackoverflow.
Si vous vous assurez que tous les utilisateurs réservés, dans chacun des contextes concernés, ignorent les clés impossibles à résoudre, 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 le ignore-unresolvable
La proprié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.
Pour ignorer une ressource externe manquante, il faut:
ignore-resource-not-found="true"
Juste au cas où quelqu'un d'autre se cogne dessus.
Vous pouvez avoir plusieurs <context:property-placeholder />
éléments au lieu de déclarer explicitement plusieurs beans PropertiesPlaceholderConfigurer.
Le bean PropertiesPlaceholderConfigurer
a une propriété alternative appelée "propertiesArray". Utilisez ceci à la place de la propriété "properties" et configurez-le avec un <array>
de références 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, quelques bonnes pratiques doivent être suivies:
l'attribut d'ordre doit être spécifié pour fixer l'ordre dans lequel ils sont traités par Spring. Tous les espaces réservés de propriété, moins le dernier (ordre le plus élevé), doivent avoir
ignore-unresolvable=”true”
pour permettre au mécanisme de résolution de passer aux autres dans le contexte sans lever d'exception
source: http://www.baeldung.com/2012/02/06/properties-with-spring/