chargement du fichier de propriétés au printemps

L'un de notre équipe a mis en place le chargement des propriétés de cette façon (voir le pseudo-code ci-dessous) et conseille cette approche est juste que le client demande de l'aide c'est libre de garder les propriétés dans un fichier quelconque. Contrairement à l'opinion largement utilisé propertyplaceholderconfigurer.

application-context.xml

<bean class="com.mypackage.Myclass">
<property name="xml" value="classpath:"{com.myapp.myproperty1}"> </property> 
</bean>

config.propriétés

com.myapp.myproperty1=data.xml

edit: je devrais l'avoir ajouté les données.propriétés et non data.xml. Nous voulons charger un fichier de propriétés (ce fichier de propriétés est donné dans le fichier de configuration.propriétés en tant que "propriété".
com.myapp.myproperty1=données.propriétés

classe java

import org.springframework.core.io.Resource;
public class Myclass {

private Resource xmlField;

//setter & getter methods..

}

Est-il le droit d'utiliser ressort.io.Ressources?

Une autre raison est l'application client souhaite charger un environnement de configuration spécifique. J'ai suggéré d'utiliser le propertyconfigurer et l'utilisation des profils maven pour générer de l'environnement de build spécifique

Pouvez-vous me conseiller lequel est le mieux adapté auquel cas? et si elle est différente dans différents scénarios, s'il vous plaît aidez-moi de faire remarquer?

grâce

OriginalL'auteur Sandeep | 2011-11-11

  1. 10

    Vous pouvez mettre les propriétés d'un fichier et d'utiliser PropertyPlaceholderConfigurer. Voici un exemple qui répond à la fois à votre collègue de préoccupations et de votre désir de l'environnement spécifique des choses:

    <bean id="propertyPlaceholderConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="locations">
        <list>
            <!-- default settings -->
            <value>classpath:MyCompany.properties</value>
            <!-- environment-specific settings -->
            <value>classpath:MyCompany.${mycompany.env:dev}.properties</value>
            <!-- keep your coworker happy -->
            <value>classpath:${mycoworker}</value>
            <!-- allows emergency reconfiguration via the local file system -->
            <value>file:///${user.home}/MyCompany.properties</value>
        </list>
    </property>
    <property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE"/>
    <property name="ignoreResourceNotFound" value="true" />
    <!-- should be validated separately, in case users of the library load additional properties -->
    <property name="ignoreUnresolvablePlaceholders" value="false"/> 
</bean>

    Si vous passez pas de -D arguments, alors vous allez ramasser les propriétés suivantes des fichiers, où les propriétés dans le plus tard, fichiers remplacer les valeurs précédemment déterminées.

    1. MyCompany.propriétés le classpath
    2. MyCompany.dev.propriétés le classpath
    3. $HOME/MyCompany.propriétés si il existe

    De swap dans une production de config pour le #2, il suffit de passer -Dmycompany.env=prod à java. De même, votre collègue peut passer -Dmycoworker=/some/path/config.properties si il/elle veut.

    J'ai oublié d'appuyer sur soumettre sur cette réponse, donc maintenant il reprend certaines des informations que d'autres ont fourni. Encore, je vais le laisser ici au cas où quelqu'un trouve le plus de détails pour être utile.
    +1, toujours de bonnes infos.

    OriginalL'auteur jtoberon

  2. 5

    Je ne suis pas sûr pourquoi un PropertyPlaceholderConfigurator n'aurait pas été le bon choix.

    J'ai presque toujours spécifiques à l'environnement configs par une mesure PPC qui peut soit (a) obtenir un -D paramètre au démarrage, et/ou (b) utiliser le nom de la machine, pour le choix des propriétés de fichier à charger.

    Pour moi, c'est plus pratique que de regrouper les informations dans la via Maven, puisque je ne peux plus tester facilement arbitraire configurations de la machine je suis sur (à l'aide d'un -D propriété).

    +1, je suis d'accord, à moins que exécution recherche est souhaitée, je pense que ProperyPlaceholderConfigureer ou la @Value(..) approches sont à préférer.
    edit: je devrais l'avoir ajouté les données.propriétés et non data.xml. Nous voulons charger un fichier de propriétés (ce fichier de propriétés est donné dans le fichier de configuration.propriétés en tant que "propriété". com.myapp.myproperty1=données.propriétés En bref, de charger un fichier de propriétés dont l'emplacement et le nom est dans une propriété. Cela peut-il être fait?
    Vous pouvez créer un PropertyPlaceholderConfigurator pour rechercher des valeurs autant que vous le souhaitez, y compris la lecture à partir d'un fichier de propriétés pour créer sa liste de biens emplacements des fichiers.

    OriginalL'auteur Dave Newton

  3. 3

    +1 pour Dave suggestion. Vous devriez être en utilisant PropertyPlaceholderConfigurer pour le chargement de\lecture des propriétés. Voici l'exemple que j'ai sorti de mon précédent projet si vous vous demandez comment les utiliser. Cet exemple est pour le chargement de plusieurs fichiers de propriétés, mais le concept est le même. Bonne chance.

    <bean id="projectProperties" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
    <property name="locations">
        <list>
            <value>classpath:config.properties</value>
        </list>
    </property>
</bean>

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
        <property name="properties" ref="projectProperties" />
</bean>

<bean id="uniqueAssetIdRetriever" class="com.mypackage.Myclass">
    <property name="xml" value="${com.myapp.myproperty1}" />
</bean>
    Les propriétés nom "xml" est HashMap?

    OriginalL'auteur skusunam