Modèles de configuration d'application Web Java

Question

Existe-il des modèles ou des meilleures pratiques qui peuvent être utilisés pour simplifier la modification des profils de configuration pour les applications web java dans plusieurs environnements. par exemple JDBC Url, SAVON, etc.

Comme un peu de fond pour aider à clarifier ma question, je travaille avec plusieurs grandes applications web java que pendant un cycle de mise à déplacer dans 6 environnements différents; le développement, l'intégration, l'assurance qualité, de la performance et, éventuellement, obtenir déploiement sur plusieurs serveurs de production. Dans chaque environnement, des besoins de configuration à modifier. Aujourd'hui, la plupart des modifications de configuration pour chaque déploiement sont fait manuellement, ce qui prend du temps et de l'ouvrir à des erreurs.
Est-il possible de prendre le manuel d'intervention de ce processus?

Answer 1

Je suis surpris que personne n'a cité le Jakarta Commons Configuration de l'API (http://commons.apache.org/configuration/) pour répondre à cette question. Il vous permet d'avoir une hiérarchie de fichiers (ou autre configuration de sources telles que XML, JNDI, JDBC, etc.). C'est ce que Jeremy Seghi était en train de parler et il vous donne une bonne façon d'avoir les valeurs par défaut et de priorités locales.

La meilleure partie est qu'il est testé solution de travail de sorte que vous n'avez pas à aller de l'artisanat quelque chose de vous-même.

Answer 2

J'ai tendance à travailler plus avec .NET ces derniers temps, donc mon Java est assez rouillé. Je suis sûr que ce serait de travailler dans n'importe quelle langue avec un peu de peaufinage.

Nous utilisons une extension de l' .NET configuration du système qui nous permet d'utiliser l'environnement et/ou de l'application ou des paramètres spécifiques en conjonction avec un traitement plus global de la configuration. Le système de configuration utilise un paramètre Global pour chaque machine de l'identifier en tant que dev, bêta, ou de la production (valeur par défaut). Un ensemble de fichiers chargés dans l'ordre, et le réglage de la dernière fichier remplace un paramètre a été défini antérieurement fichier chargé. Les fichiers sont chargés dans l'ordre suivant:

1. Paramètres globaux
2. Paramètres spécifiques à l'Application
3. L'Application spécifique de l'environnement remplace

Tous les fichiers sont dans le contrôle de code source, et puisque l'environnement est défini sur la machine, l'application est en cours d'exécution; car il ne pas accéder à la version "beta" de la configuration, à moins que la configuration de la machine qu'il identifie comme "bêta", nous pouvons à la promotion de tous les fichiers de configuration sans crainte de, par inadvertance, en pointant notre application de production à un dev de la base de données.

Answer 3

Voici quelques-unes des pratiques que j'ai utilisé ou rencontrés. La combinaison de ces est généralement nécessaire dans la pratique.

En substituant les valeurs de la variable dans conffiles lors de la construction de

Voici un exemple de comment cela peut être fait avec Apache Ant. Propriétés Ant (${var.name}) peut être contrôlé avec la génération des fichiers de configuration:

<filterset id="variables.to.replace">
    <filter token="APPNAME" value="${app.name}"/>
    <filter token="WEBAPP-PATH" value="${webapp.path}"/>
    <filter token="ENCRYPT-ALGORITHM" value="${encrypt.algorithm}"/>
    <filter token="ERROR-MAILTO" value="${error.mailTo}"/>
    <!--...-->
</filterset>

<!-- Then, when building & copying the conf, replace the variables: -->
<copy todir="${properties.target.dir}">
    <!-- env specific conf files -->
    <fileset dir="${basedir}/env/${run.env}/webapp/WEB-INF/classes" />
    <filterset refid="variables.to.replace"/>
</copy>

La bonne chose est que vous obtenez une amende de contrôle sur les différentes configurations au moment de la construction. Ce qui est mauvais, c'est que le système tend à se développer très complexe et difficile à maintenir si vous utilisez cette méthode à grande échelle pour un grand nombre de configurations différentes. Aussi, la construction du conffiles, aussi, le moyen le plus lent, les cycles de développement.

En substituant les variables de conf à l'intérieur de guerre à webapp de démarrage

C'est ce que j'ai l'habitude de le faire lors de l'utilisation de Spring Framework, même si il y a juste un possble de configuration, de bénéficier des avantages de la séparation des préoccupations. Avec le Printemps, vous pouvez avoir la conf valeurs remplacé par PlaceholderPropertyConfigurer à l'intérieur de Printemps contexte à webapp de démarrage. Dans ce cas, vous avez de toute façon choisir la bonne configuration, qui peut être configurée par exemple sur le temps de construction.

Par rapport au moment de la construction du remplacement, il est plus facile de temporairement manipuler les valeurs compressé webapp, si nécessaire. Bien sûr, la webapp doit être redémarré si vous changer quoi que ce soit, et le manuel, les modifications ne sont pas conservées entre webapp redéploiements. Le printemps est aussi limitée pour le Printemps contexte, si cela ne marche pas' par exemple web.xml (mais d'avoir des variables dans web.xml devrait probablement être évité toute façon à cause de ses limites).

La lecture de la locale conf à partir du fichier

Cette approche est probablement la plus simple à mettre en place: il suffit d'inventer un chemin du fichier de configuration, par exemple, $HOME/mywebapp/conf.properties et faire de votre webapp en quelque sorte le lire au démarrage.

La bonne chose ici est que vous n'avez pas à se préoccuper de la conf lors de la construction/déploiement de la webapp. De toute façon, vous devriez avoir un peu sensible conf par défaut qui peut alors être remplacée par la résolution conf.

Avoir la conf dans une base de données

C'est la solution la plus flexible pour annuler les conf les paramètres, mais peut aussi devenir compliqué dans certains cas. Avoir la conf dans un tableau avec name et value colonnes devrait fonctionner pour la plupart des cas.

Bien sûr, vous ne pouvez pas configurer la connexion JDBC url dans une table de base de données, mais c'est une bonne solution pour de simples textuelle/numérique conf qui affecte la webapp de l'opération après la connexion db a été mis en place. Pour éviter une dégradation de la performance, assurez-vous de mettre en cache la conf en quelque sorte, si il sera fréquemment utilisés.

Extra pratiques

Comme l'a souligné kgiannakakis, il contribue également à définir une configuration de la page de diagnostic de certains type de votre application.

Answer 4

Ce est lourdement, va dépendre de ce que les options les serveurs d'application web vous donner. Nous avons plusieurs environnements de JBoss avec différentes Url JDBC, JNDI nom reste le même sur tous les serveurs, la configuration de l'instance locale de changements, de sorte que rien ne va mal, de construire de construire.

Je suppose que la réponse courte est que la meilleure pratique consiste à externaliser les configurations et de garder un bon fichier avec les paramètres corrects pour chaque serveur, et ont la web app de lecture de la configuration. La nature exacte de l'externalisation et de la lecture, va dépendre de la configuration et l'application serveur.

EDIT: Ces configurations ne pas exister en tant que partie de la guerre (l'oreille dans notre cas) de cette façon, ils ne sont pas remplacés.

Answer 5

Premièrement, tous les paramètres de configuration qui changent fréquemment en un seul endroit. Il est vraiment difficile, si vous avez besoin de configurer JNDI, modifier les valeurs de base de données et modifier les propriétés des fichiers, tous en même temps, afin de terminer la configuration. Préférez le milieu qui est plus facile à modifier et également plus facile à vérifier que tout est correctement configuré. Je dirais que les fichiers de propriété est la meilleure solution. Vous pouvez facilement les modifier et vous avez seulement besoin d'un rapide coup d'œil à travers eux de voir que tout va bien. Si vous optez pour les fichiers de propriétés, sélectionnez avec soin un emplacement standard pour eux et de lui affecter une variable d'environnement pour le chemin d'accès.

Il aide également si vous avez un simple test qui vérifie que tout est mis en place correctement. Par exemple, vous pouvez avoir une page de test qui affiche les paramètres de configuration et effectue des tests de base, comme essayer de se connecter à la base de données ou des serveurs distants.