J'ai un Spring application-context.xml avec PropertyPlaceholderConfigurer pour obtenir les valeurs des propriétés du fichier .properties. Les dossiers sources principaux et de test ont un fichier .properties séparé. Le problème est que je dois utiliser des variables d'environnement dans le fichier .properties. Mais quand je le fais de la manière suivante:
property.name=${env.SYSTEM_PROPERTY}
Je reçois l'erreur suivante:
org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean definition with name 'beanName' defined in class path resource [com/example/applicationContext.xml]: Could not resolve placeholder 'env.SYSTEM_PROPERTY'
tandis que le paramètre fictif est défini comme
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location" value="classpath:com/example/application.properties"/>
</bean>
Avez-vous des idées pour que property.name soit interprété comme une variable d’environnement (et non comme un espace réservé)?
Cordialement, Dmitriy.
Je changerais probablement la solution complètement: injecter directement la propriété du système, par opposition à la propriété qui fait référence à une propriété du système
Par exemple.
@Value("#{ systemProperties['Java_MY_ENV'] }")
private String myVar;
ou
<property name ="myVar" value="#{systemProperties['Java_MY_ENV']}"/>
J'utilise un configurateur de propriété comme celui-ci
<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>classpath:someprops.properties</value>
</list>
</property>
<property name="ignoreResourceNotFound" value="true" />
<property name="searchSystemEnvironment" value="true" />
<property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE" />
Vous devez également vous rappeler de passer le paramètre dans le programme en utilisant
-DJAVA_MY_ENV=xyz
Ainsi, lorsque vous exécutez la version de production, vous pouvez réussir une chose et lorsque vous exécutez des tests, une autre.
De plus, ce que je fais souvent ressemble à ceci:
<property name="locations">
<list>
<value>classpath:someprops.properties</value>
<value>classpath:someprops-{environment}.properties</value>
</list>
</property>
où environnement est prod/stage/test/int/ci/local (1 par environnement - vous ne pouvez en avoir que 2 ou 3 pour le moment). Vous pouvez transmettre la variable d'environnement au programme. Toutes les propriétés qui devraient être identiques, que leur production/exécution sur votre ordinateur/vos tests locaux soient ou non dans le fichier de propriétés someprops.properties. Tous ceux spécifiques à l'environnement/la manière dont ils sont exécutés iront dans le fichier plus spécifique (vous devriez le mettre dans le fichier someprops.properties ainsi qu'un fichier par défaut, à moins que le mécanisme ne soit surchargé)
Par exemple. dans classpath: someprops.properties
url=www.mysite.com
dans classpath: someprops-local.properties
url=localhost
En utilisant cette idée de base, vous pouvez séparer les tests des propriétés d'exécution normales du programme.
En utilisant:
<context:property-placeholder location="classpath:env.properties"/>
Change ton:
property.name=${env.SYSTEM_PROPERTY}
À:
property.name=${SYSTEM_PROPERTY}
J'utilise Spring 3.0.4.LELEASE, mais je ne sais pas quand cela a été introduit.
J'ai utilisé l'approche de benkiefer, mais j'ai dû ajouter un auditeur à web.xml:
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>