Je me demande comment les gens gèrent à la maintenance des ressources JNDI sur plusieurs instances de leur serveur d'applications Tomcat. Permet de prendre, par exemple, ma base de données JNDI. Il est déclaré dans mon fichier /conf/context.xml de mon fichier et de mes références de mon fichier web.xml d'applications.
Cette ressource JNDI doit être définie de manière indépendante sur ma boîte de développement, ma boîte à étagères et une boîte de production. Et si je veux configurer une nouvelle instance d'une boîte de développeur / mise en scène / production? Cela signifie que je dois recréer le nom de ressource à l'intérieur du contexte.xml pour chaque nouvel instance que j'abandonne? Dans une perspective d'installation, il s'agit d'un endroit où il pourrait y avoir une erreur humaine pouvant entraîner un serveur d'applications pour commencer à pointer sur le mauvais DB.
Je trouve cela à être lourd et confus au fur et à mesure que j'ajoute à la fois le nombre de développeurs sur mon projet ainsi que le nombre de serveurs de production que je pourrais utiliser.
Faites-vous simplement une partie de votre configuration ou créez-vous un script de configuration qui traite de cela pour vous chaque fois que vous réinstallez Tomcat et configurez une boîte? Ou existe-t-il un autre niveau d'indirection qui pourrait rendre cela plus facile?
6 Réponses :
Déploiez-vous plusieurs applications Web qui doivent utiliser Ressources partagées ?
Si non, il n'y a absolument aucune raison de déclarer vos ressources dans /conf/context.xml. Ils devraient plutôt être déclarés dans un fichier de contexte distinct et privé à votre application Web .xml qui sera déployé comme /meta-inf/context.xml dans votre guerre. Ce fichier, ainsi que votre web.xml, vous devez être vérifié dans votre système de contrôle source et être déployé dans le cadre de votre intervention manuelle - aucune intervention manuelle.
Si vous déployez plusieurs applications Web avec des ressources partagées, vous pouvez écrire une usine de ressource personnalisée qui exposerait la même ressource à plusieurs webapps (voir
Les votes de la route sont vraiment ennuyeux. Si vous avez voté quelqu'un, avez du courage et laissez un commentaire pourquoi. Cela va au double pour quand vous pensez avoir dit quelque chose de mal dans ma réponse - comment voudriez-vous apprendre?
Je n'ai pas voté mais je suis fortement en désaccord avec vous. Des ressources telles que JDBC Datasources et Séance de courrier ne doivent jamais être définies dans la guerre elle-même. Les paramètres de connexion de base de données sont des propriétés de l'environnement et non de l'application. Il faut être capable de déployer la guerre dans un environnement de test avant sa production.
Je suis d'accord avec Maurice mais je pense que CHSSPLY76 vaut la peine de voter parce qu'il donne une réponse à la question. IIRC BEA Weblogic a une "proxy JNDI" qui permet de créer une référence JNDI pointant vers une autre ressource JNDI
@MAURICE - Vous êtes absolument correct sur les ressources étant propriétés de l'environnement. Cependant, je ne suis pas d'accord sur le fait que la guerre la guerre doit être déployée sur Dev Box, QA et Production - Décision d'inclure / excluez le contexte.xml dans le fichier de guerre CanBe déclenché par une propriété de construction, par exemple. La question initiale était "Comment l'automatiser pour plusieurs développeurs" - le faire dans context.xml est extrêmement simple. Devriez-vous "automatiser" plusieurs déploiements de production / de mise en scène de la même manière? Bien sûr que non.
Déploiement du fichier de guerre idem QA et PROD vous donne l'assurance que rien n'aurait pu changer entre tests et vivre en direct. Ce que vous ne voulez pas, c'est d'espérer que vous n'avez pas oublié de vérifier la bonne version du fichier de configuration pour la construction de la production. Cela signifie également ne pas avoir à avoir 200 versions du fichier de configuration pour chaque transition de ProD Retour sur Dev (Patch) à tester pour revenir à Dev (amélioration) à tester à prod, etc.
@Kelly - Ce que je ne veux pas, c'est d'enregistrer des fichiers de configuration locaux du tout. Construit qui se déploient à la mise en scène / la production proviennent de la boîte CI qui possède sa propre construction.Properties; Dev Dev. Construit utilise une configuration uniforme et obtenez donc tout du contrôle de la source. Je le fais depuis longtemps. Je ne peux pas vous dire combien de fois j'ai dû traiter de "ma construction échoue" provenant du nouveau développeur, car ils n'ont pas configuré quelque chose quelque part. Oui, nous avons un joli "nouveau développement de développement détaillé" Wiki et non, cela n'a pas aidé. Le remplacer par "caisse; fourmi tous".
Le point de JNDI est d'avoir des ressources spécifiques à l'environnement définies de manière indépendante. Vos environnements de développement, de mise en scène et de production ne doivent pas partager la même base de données (ou en tout cas, JNDI a été conçu pour permettre des bases de données distinctes pour chaque environnement).
Si d'autre part, vous essayez de charger plusieurs serveurs TOMCAT, et que vous souhaitez que toutes les instances partagent la même configuration, je pense que vous pourriez toujours séparer votre contexte.xml et avoir les bits communs dans un fichier partagé. Voici le Documentation Tomcat parle de context.xml .
Comment vous gérez ceux-ci est à vous. Il peut être simple, comme ayant un "modèle" context.xml de fichiers que vous commencez avec chaque fois que vous créez une nouvelle instance Tomcat (les avoir dans un système de contrôle source, en particulier une distribution, peut être utile). Ou vous pouvez écrire un script pour le faire.
Si vous voulez plus, je pense qu'il y a des produits qui mettent une bonne interface utilisateur autour de l'ensemble du processus. On pense que ceci est Springsource TC Server .
Je ne partagerai pas le même dB parmi tous les différents serveurs. Comment êtes-vous censé partager un contexte commun.xml parmi diverses boîtes de serveur? De plus, si même il semble que je dois maintenir divers context.xml pour chaque case quels sont les bons processus / pratiques d'automatisation de ces tâches et de réduire les erreurs humaines?
Je ne pense pas que vous puissiez réellement partager des fichiers entre les différentes cases sans recourir à des systèmes de fichiers partagés (par exemple, NFS avec des liens symboliques). J'ai également mis à jour la réponse pour référencer le document Tomcat qui parle de la configuration context.xml.
Je suppose que pour une ressource donnée, vous utilisez le même nom JNDI dans chaque environnement. Sinon, vous devez modifier votre code pour indiquer le nom de la nouvelle ressource (JNDI).
Configuration de l'environnement La première fois peut être presque impossible à tester à l'avance. Il n'y a aucun moyen de vérifier que certaines chaînes, telles que la chaîne de connexion de la base de données de production, n'ont pas obtenu de graisse avant de devoir l'utiliser. C'est la nature de la configuration de l'environnement. Avec cela, si vous souhaitez réduire le capot probable des erreurs, vous devez d'abord vous assurer que chaque ressource est donnée un nom utilisé indépendamment de l'environnement hébergé. Créez un nom de ressource DBConnectionsRing dans un fichier de propriétés qui pointe vers JNDI: / JDBC / MyProject / Ressources / DBConnections et assurez-vous que tous les environnements déclarent la même ressource. Vous trouverez ci-dessous comment nous avons gardé le code isolé de ces types de dépendances environnementales. Cela étant dit, vous devrez toujours vérifier manuellement que la configuration d'un serveur spécifique utilise les valeurs appropriées pour les ressources définies.
Remarque: jamais Créez des noms de ressources comme " dbprodrConnectionsRing ", " dbqaconnectionstring ", " dbdevconnectionstring ". Vous vaincuez le but d'essayer d'éliminer l'intervention manuelle, car vous avez ensuite ajouté une étape d'indirection qui aura besoin d'un changement de code (pour pointer le code au nom de la ressource correct) et créer (pour emballer les modifications dans votre fichier .war. ) lors du déplacement entre les environnements. Ce que nous avons fait était de créer une structure de dossiers pour les propriétés spécifiques à l'environnement. Dans ce dossier, nous avons créé des dossiers pour chaque environnement spécifique ciblé pour le déploiement, y compris le développement local. Cela ressemblait à ceci: Dans chaque dossier, nous mettons des copies parallèles des fichiers de propriétés / de configuration et mettez les différentes configurations uniquement dans le fichier dans le dossier approprié. Le secret était de contrôler la classe de classe de l'environnement de déploiement. Nous avons défini une entrée de propriétés de classe de classe sur chaque serveur. Sur PROD, il serait réglé sur "$ PROJECTDIR / Propriétés / ProD" lors de tester la même variable serait défini sur "$ PROJECTDIR / Propriétés / Test". De cette façon, nous pourrions avoir des chaînes de connexion de base de données Pour la base de données Dev / Test / Prod, préconfiguré et ne pas avoir à commander / dans le fichier de propriétés à chaque fois que nous voulions construire pour un environnement différent. Cela signifiait également que nous pourrions déployer exactement le même fichier .war / .ear pour tester et proditer sans reconstruire. Toutes les propriétés qui n'étaient pas déclarées dans le fichier de propriétés que nous avons 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.
Ma solution consistait à mettre toutes les définitions dans un fichier Comme vous pouvez le constater, je définis les valeurs par défaut, puis spécialisez les paramètres. Dans l'environnement, j'ai ensuite écrasé certaines choses (le système local obtient une piscine plus petite que le test de production et d'intégration). Le script de filtre ressemble à ceci: serveur-template.xml , puis utilisez une transformée XSLT intelligente pour générer le fichier Server.xml server.xml dans le modèle. Tout est enregistré dans CVS, afin que je puisse restaurer rapidement l'installation sans avoir à craindre que quelque chose ne fonctionne pas. Voici ce que le modèle ressemble à:
Si vous utilisez la structure de printemps, vous pouvez résoudre ce problème très facilement à l'aide de PropertyPlaceholderconfigurier . Cette classe vous permet de déplacer les définitions en fichiers de propriétés externes. La configuration de la source de données est la suivante: Les propriétés elles-mêmes sont définies dans un fichier de propriétés standard: p> pour les propriétés réelles que vous avoir deux options: p> Placez le fichier de propriétés à l'extérieur du système de fichiers, il sera donc différent sur chaque machine: p>
Ajoutez la propriété système suivante à votre serveur -Denv = [Développement | Test | Production]. Ensuite, mettez trois fichiers de configuration dans votre répertoire Web-Inf / Classes: JDBC-Development.properties, Test-Development.Properties et production-Development.properties. La configuration de contexte sera: p>
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location">classpath:jdbc-${env}.properties</property>
</bean>
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location">file:/etc/yourapp/jdbc.properties</property>
<!-- on windows, put the file in c:\etc\yourapp, the definition will work -->
</bean>
Si vous êtes capable de lier un annuaire JNDI distant sur le répertoire JNDI "global" de Tomcat, vous pouvez utiliser ce mécanisme: Utilisation d'une source de données JNDI créée par une autre application avec Tomcat
Cordialement.