2009-07-16 11 views
1

Salut Comment auriez-vous résolu cela?différents fichiers de configuration pour différents serveurs

J'ai une application dans laquelle j'ai quelques fichiers de configuration, je fais un fichier war et le déploie sur le tomcat.

Mais en même temps, je dois faire le fichier war et déployer la même application dans un contexte différent et/ou un serveur avec des fichiers de configuration modifiés.

Je peux créer ma propre tâche dans ant, et remplacer les paramètres nécessaires, mais il peut y avoir une possibilité de passer à maven, et de toute façon je ne suis pas sûr à ce sujet. Ou est-ce que je peux utiliser quelque chose comme le configurateur de porte-lieu de propriété de ressort ou jgroups

Répondre

1

Le ressort peut très bien gérer ceci de diverses manières. L'approche que j'ai trouvée la plus utile et la plus flexible consiste à configurer dans chaque environnement une variable système qui spécifie le nom de l'environnement trhe. test, dev, int, prod, etc.

Spring peut ensuite utiliser cette variable système pour charger les fichiers de propriétés corrects. Selon vos besoins, ces fichiers de propriétés peuvent être regroupés avec l'application ou chargés à partir d'un emplacement externe. Theres un exemple d'une approche similaire ici:

http://www.developer.com/java/ent/print.php/3811931

+0

et est-il possible de l'utiliser pour faire le fichier de guerre avec un peu de fichiers de configuration modifiés bits fichier? par exemple. pour un fichier de guerre dans quelque chose.properties adresse de la propriété = un et pour le deuxième fichier de guerre dans le même fichier something.properties address = second? thx – blefesd

+0

@blefesd - en bref non. Cependant je conseille de ne pas prendre cette approche. Il est préférable d'avoir une seule version de déployables et d'avoir toute la configuration incluse ou chargée à partir d'emplacements externes. Certaines raisons à cela sont la facilité de version, la capacité d'ajouter de nouveaux environnements et la traçabilité. – Pablojim

0

Je applications de déployer Spring emballés comme WAR soit Tomcat ou WebLogic sans aucune modification. Il contiendrait à la fois le fichier META-INF/context.xml pour Tomcat et weblogic.xml pour WebLogic. Pas de soucis, pas de changements.

0

Nous avons créé une structure de dossiers pour les propriétés spécifiques à l'environnement. Sous ce dossier, nous avons créé des dossiers pour chaque environnement spécifique ciblé pour le déploiement, y compris le développement local. Il ressemblait à ceci:

Project 
\ 
-Properties 
\ 
    -Local (your PC) 
    -Dev (shared dev server) 
    -Test (pre-production) 
    -Prod (Production) 

Dans chaque dossier, nous mettons des copies parallèles des propriétés/fichiers de configuration et de mettre les différentes configurations que dans le fichier dans le dossier approprié. Le secret consistait à contrôler le chemin de classe de l'environnement de déploiement. Nous avons défini une entrée de chemin de classes PROPERTIES sur chaque serveur. Sur Prod, il serait défini sur "$ ProjectDir/Properties/Prod" tandis que sur Test, la même variable serait définie sur "$ ProjectDir/Properties/Test". De cette façon, nous pourrions avoir des chaînes de connexion à la base de données dev/test/prod préconfigurées et ne pas avoir à extraire/dans le fichier de propriétés chaque fois que nous voulions construire pour un environnement différent. Ceci signifiait également que nous pouvions déployer exactement le même fichier .war/.ear pour tester et produire sans reconstruire. Toutes les propriétés qui n'ont pas été déclarées dans le fichier de propriétés ont été traitées de la même manière en utilisant le même nom JNDI dans chaque environnement, mais en utilisant des valeurs spécifiques à cet environnement.

0

http://www.gifnoc.com/config pourrait aider car il stocke la configuration sur une place centrale et le client tire de celui-ci pour les différents environnements

Questions connexes