PropertyPlaceholderConfigurer vs Filtres - Haricots de printemps

Question

J'ai une question concernant la différence entre PropertyPlaceholderConfigurer (org.springframework.beans.factory.config.PropertyPlaceholderConfigurer) et les filtres normaux définis dans mon pom.xml.

J'ai regardé des exemples, et il semble que même si les filtres sont définis et marqués comme étant actifs par défaut dans le fichier pom.xml, ils utilisent encore PropertyPlaceholderConfigurer dans le fichier applicationContext.xml de Spring. Cela signifie que le fichier pom.xml fait référence à un fichier filter-LOCAL.properties alors que le fichier applicationContext.xml fait référence à application.properties et que les deux contiennent les mêmes paramètres.

Pourquoi est-ce? Est-ce ainsi que c'est censé être fait? Je suis capable d'exécuter l'objectif mvn jetty: exécuter sans l'application.properties présente, mais si j'ajoute des paramètres à l'application.properties qui diffèrent des filter-LOCAL.properties, ils ne semblent pas redéfinir.

Voici un exemple de ce que je veux dire:

pom.xml

 
    <profiles> 
     <profile> 
      <id>LOCAL 
      <activation> 
       <activeByDefault>true 
      </activation> 
      <properties> 
       <env>LOCAL 
      </properties> 
     </profile> 
    </profiles> 

applicationContext.xml

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

    <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> 
     <property name="driverClassName" value="${jdbc.driver}"/> 
     <property name="url" value="${jdbc.url}"/> 
     <property name="username" value="${jdbc.username}"/> 
     <property name="password" value="${jdbc.password}"/> 
    </bean> 

un exemple du contenu de application.properties et filters-LOCAL.properties

 
jdbc.driver=org.postgresql.Driver 
jdbc.url=jdbc:postgresql://localhost/shoutbox_dev 
jdbc.username=tester 
jdbc.password=tester 

Puis-je supprimer le propertyConfigurer du applicationContext, créez un filtre PROD et ne pas tenir compte du fichier application.properties, ou la volonté qui me donne des problèmes lors du déploiement sur le serveur de production?

Answer 1

Vous devriez plutôt utiliser Maven pour sélectionner le fichier de propriétés Spring à utiliser selon l'environnement pour lequel vous construisez. Lorsque vous testez dans votre IDE, vous devez simplement démarrer le conteneur Spring à partir du test sans utiliser Maven pour autre chose que la gestion de vos dépendances.

Answer 2

Pour mémoire, voici ce que l'auteur de la série blog OP suit écrit dans this comment:

Je l'habitude d'être un grand fan de printemps PropertyPlaceholderConfigurer mais jamais depuis que je commencé à utiliser maven Je ne trouve aussi utile que les filtres de Maven, l'aide d'un fichier de filtres comme expliqué ici, ou en ayant plusieurs profils dans la pom pour les différentes couches de déploiement à chaque profil spécifiant les propriétés.

Le plus grand reproche que j'ai avec le PropertyPlaceholderConfigurer est que vous ne pouvez avoir qu'un seul PropertyPlaceholderConfigurer haricot. Et ce n'est pas bien documenté. Avec les fichiers de filtre de maven, vous pouvez avoir autant de fois que vous le souhaitez.

L'autre raison pour laquelle je préfère les filtres de Maven est que, avec eux, vous pouvez faire un « mvn package » et fouiner dans le répertoire cible et du globe oculaire les fichiers de configuration filtrés et voir ce qu'il a fait. Avec PropertyPlaceholderConfigurer du printemps ne pas trouver ce qui a été remplacé jusqu'à ce que l'application est démarrée.

Je seconde cette opinion et préfèrent l'approche de filtre sur l'utilisation du PropertyPlaceholderConfigurer et le plugin AntRun pour copier dire test.properties dans application.properties lors de l'exécution de mes tests. Et en utilisant les ressources filtrées est bien supporté par tous les principaux IDE (Eclipse, IntelliJ, NetBeans) donc je ne vois pas pourquoi je ne devrais pas l'utiliser.