J'ai plusieurs classes qui doivent charger certains fichiers de propriétés et je me demandais quelles sont les meilleures pratiques pour accomplir cela. J'ai pensé à deux approches de base:
codez le nom du fichier de propriétés dans chaque classe, puis utilisez la classe CODE> Propriétés CODE> pour charger à partir d'un fichier Créez une méthode qui, étant donné un nom de classe, chargez un fichier de propriétés qui a le même nom que la classe. Bien que cette approche ne nécessite pas de corriger le nom du fichier de propriétés, il exige que nous suivions une convention de nommer les fichiers, ce qui peut provoquer une confusion. P>
FileInputStream code>, qui peut être problématique si une personne décide de changer Le nom du fichier de propriétés, car il est codé dans le code. P>
public class A {
public A() {
Properties p = PropertiesHelper.loadFromClassName(A.class.getName());
// here, we **assume** that there is a A.properties file in the classpath.
}
}
public class A {
public A() {
Properties p = new Properties().load(
new FileInputStream("properties/Aconfig.properties"));
String value = p.getProperty("key", "");
}
}
5 Réponses :
Dans le passé, j'ai chargé des propriétés via une propriété système - le nom du fichier est transmis via la propriété système et je charge ce fichier. Il y a un nom par défaut que nous utilisons si la propriété système n'est pas définie. Si le fichier n'existe pas, vous devez décider quoi faire là-bas.
La bonne chose à ce sujet est une norme est une norme, mais elles peuvent remplacer son emplacement / nom à l'aide d'un argument de ligne de commande.
juste mes 2 cents cependant.
avoir plusieurs endroits pour les fichiers de propriétés et les charger (l'un après l'autre) dans un seul objet de propriétés. Ce schéma permet à un mappage d'avoir une valeur par défaut qui peut ensuite être remplacée à plusieurs points.
Les noms de fichier peuvent facilement être transmis dans la ligne de commande de l'application. Cela peut être fait soit en tant que ARG à la méthode principale (après le nom de la classe principale) ou en tant que propriété (comme les aperkins font allusion, je crois) à l'aide de -D flag .
Je suis au courant de cela, mais j'ai besoin de ma demande de travail dans un environnement Web. En outre, j'ai beaucoup de noms de fichiers à réussir et je devrais changer de script de course.sh (ou similaire) à chaque fois que j'ai créé un nouveau, en utilisant cette méthode.
Si vous avez codé sur vos noms de fichiers, vous êtes dans une position similaire. Vous pouvez avoir un nom de fichier sur la ligne de commande contenant une liste de fichiers de configuration dont vous avez besoin.
La pratique Il résout toutes sortes de problèmes - vous ne liez pas votre classe à un nom de fichier de propriété particulier, vous n'avez pas à vous soucier de charger lesdites propriétés dans cette classe et de gérer des exceptions possibles et vous n'avez pas à passer 30 noms de fichiers de propriété en tant qu'arguments de ligne de commande (ou propriétés du système).
Cela aide également à beaucoup, beaucoup d'autres choses en plus de la chargement de biens :-) - essayez-la, et vous vous demanderez comment vous avez jamais vécu sans.
Mise à jour: Incidemment, Votre autre question est également une de ces choses que le printemps prendrait en charge.
Mise à jour n ° 2: Je viens de réaliser que j'ai
Oui :), j'envisage d'utiliser SF pour ce problème particulier. Cependant, pour cela, je souhaite que les fichiers de propriétés soient facilement configurés / modifiés par tout le monde (pas nécessairement un programmeur informatique), d'où la nécessité d'une simple "clé = de la valeur".
Vous pouvez encore beaucoup faire ça. Le printemps a une très belle couche d'abstraction de ressources: static.springsource.org /Spring/docs/2.5.x/Reference/Reference/... qui vous permettrait de traiter avec ces fichiers de propriété "tels quels" sans lier vos classes directement.
Hmm, je vais en lire à ce sujet, merci. Je pensais que vous faisiez référence à l'élément
Je suggérerais d'éviter d'utiliser des chemins connexes du fichier et du système de fichiers. Il est généralement préférable d'utiliser des chemins de classe de classe (HMM, sans jeu de mots ...) parce que: - Il rend votre code testable en se distinguant des chargeurs de classes entre le temps d'exécution et le temps de test, quelque chose qui est routinement effectué par tout système de construction décent - Il rend votre localisation de votre code indépendant et vous permet d'ignorer les problèmes du système d'exploitation - Il fait que votre code fonctionne comme une application autonome ou dans un conteneur (léger, servlet, serveur d'applications, tout ...)
Vous pouvez jeter un coup d'œil sur la propriétéOrcesourcebundle qui a la belle fonctionnalité supplémentaire Conscient, vous pouvez donc définir différentes propriétés avec différents paramètres locaux. Notez que les paramètres régionaux peuvent être abusés pour fournir un paramétrage indépendamment des problèmes de L10N ou I18N, par exemple. J'ai utilisé sur un projet A "Windows" et une locale "Linux", car vous pouvez construire votre propre instance locale et le transmettre au chargeur.
ou vous pouvez simplement construire le chemin vous-même ... < / p>
ou vous pouvez charger vos propriétés à partir d'un flux d'entrée: hth.
Le printemps est agréable mais probablement un peu surkill pour une caractéristique aussi simple. Vous avez peut-être un coup d'œil sur Picocontainer qui est un peu plus léger que le printemps aussi loin que DI est concerné
Je négligeai probablement votre question et je vous ai donné une réponse inadéquate. Ce que j'ai déjà fait dans votre cas particulier consiste à héberger les propriétés à charger dans un fichier de propriétés racines. Quoi qu'il en soit, ces informations doivent être stockées quelque part: codé dans votre code ou dans un fichier de configuration. Mieux utiliser le même mécanisme pour tout ... Toutefois, si vos propriétés sont liées au nom de la classe, vous feriez mieux d'utiliser votre deuxième solution, mais stockez vos propriétés pour faciliter l'édition en dehors de votre arborescence principale et les ajoutez ClassePath au moment de l'exécution.