Comment fournir une configuration de contexte pour une application Web dans Tomcat?

J’ai une application Web qui s’appuie sur des ressources et des parameters à configurer après son installation, comme une connexion JDBC.

Ce que j’ai META-INF/context.xml est de fournir un META-INF/context.xml qui est copié dans [engine-name]/[server-name]/[app-name].xml par Tomcat lorsque je déploie l’application. De cette façon, tout ce que je fournis est un fichier de guerre qui peut être copié dans le dossier appBase (webapps). La documentation de Tomcat indique que si un tel fichier existe, il ne sera pas écrasé, ce qui est vraiment bien, car les modifications apscopes après le déploiement ne seront pas perdues.

Mais il y a un problème subtil ici: comme nous déployons l’application en la copiant dans le répertoire webapps, Tomcat désinstallera d’abord l’application existante ainsi que le fichier de configuration. De cette façon, le fichier de configuration sera perdu / écrasé, ce qui n’est pas souhaitable. Tomcat ne modifiera pas ce comportement à ma connaissance.

La question est la suivante: existe-t-il un moyen de contourner ce problème en installant l’application de manière à ce que Tomcat ne supprime pas le fichier de configuration existant. Ou existe-t-il un meilleur moyen d’emballer l’application?

Veuillez noter que nous ne voulons pas définir autoDeploy sur false et que nous ne pouvons pas utiliser une intervention humaine pour l’installation (ce qui exclut l’utilisation de l’application Web Tomcat Manager).

Si je récupère le fichier de configuration du fichier .war et le copie séparément sous le nom [engine-name]/[server-name]/[app-name].xml , Tomcat l’associera toujours à mon application et la supprimera une fois la copie terminée. un nouveau fichier .war.

Une autre hypothèse est la suivante: nous ne connaissons pas à l’avance les valeurs de la configuration. Nous ne fournirons qu’un exemple de configuration (un espace réservé, si vous le souhaitez) alors que la configuration réelle sera effectuée plus tard (pas nécessairement au moment de l’installation).

Merci

La solution est simple: ne mettez pas la configuration dans votre context.xml.

Voici une solution que nous utilisons (ce qui fonctionne bien pour un certain nombre de clients externes divers):

Nous avons une seule guerre qui sera utilisée dans plusieurs environnements, webapp.war. Nous avons trois environnements, développement, intégration et production. L’intégration et la production sont sur le site du client. Nous ne connaissons pas les mots de passe et les chemins d’access aux fichiers pour les sites d’intégration et de production du client.

Nous utilisons une combinaison de deux choses: la recherche JNDI pour les éléments de firebase database et les fichiers de propriétés externes.

Dans le context.xml qui est livré dans la guerre, nous avons un ResourceLink

  

Cela donne une référence à une source de données définie globalement, définie dans le server.xml pour Tomcat.

  

Les détails de la firebase database peuvent donc être modifiés en modifiant le server.xml sans modifier le webapp.war . De manière cruciale, cela ne doit être fait qu’une fois pour chaque serveur, pas au redéploiement.

Dans notre configuration printanière, pour définir la dataSource nous avons:

  

Pour les autres propriétés, nous avons un fichier global application.properties qui est fourni avec webapp.war, mais qui ne fait pas partie de la guerre. Ceci est référencé par un -D sur la ligne de commande pour démarrer Tomcat. -Duk.co.farwell.webapp.applicationDir="/usr/xxx/fff" . Nous prenons la définition et lisons le fichier de propriétés. Les éléments de la firebase database pourraient également être réalisés de cette manière, mais nous perdrions le pooling effectué par Tomcat.

Autre chose: nous n’avons pas à reconstruire si les serveurs sont déplacés ou si les machines sont modifiées pour une raison quelconque. C’est une question pour le client et son personnel d’infrastructure.

J’ai réussi à résoudre ce problème d’une manière ou d’une autre.

1- Installez un répertoire WAR éclaté quelque part en dehors de l’appBase de Tomcat, supposons qu’il se trouve dans /usr/local/MyApp . [Vous pouvez utiliser un fichier WAR pour cette étape au lieu du répertoire WAR si votre application s’exécute à partir d’une guerre non explosée.]

2- Copiez le fichier de configuration du contexte dans le [tomcat.conf]/[engine]/[hostname] , appelons-le MyApp.xml . Ce fichier indiquera l’emplacement de l’application:

      

3- Vous êtes maintenant libre d’aller modifier le fichier de configuration.

4- Mettre à jour l’application en copiant la nouvelle version de votre application dans / usr / local / MyApp

Remarques:

a) Cette solution s’applique également à un fichier .war non développé, mais comme nous utilisons Log4JConfigListener de Spring, il ne s’exécuterait pas à partir d’un fichier .war non explosé. Tomcat n’explose pas les fichiers .war placés à l’extérieur du dossier appBase (webapps).

b) Cette approche ne vous empêche pas d’avoir context.xml dans /usr/local/MyApp/META-INF/context.xml car il ne sera pas utilisé par Tomcat dans cette configuration. Vous pouvez l’utiliser dans votre environnement de développement, où vous sauvegardez votre fichier .war dans le dossier appBase (webapps).

C’est ce que j’ai eu jusqu’à présent, toujours à la recherche de meilleures solutions.

C’est ainsi que nous pouvons gérer l’externalisation du contexte webapp à partir du fichier .WAR.

  1. Placez votre fichier .WAR quelque part en dehors de tomcat
  2. Créez un fichier $ APP_NAME.xml dans le répertoire $ TOMCAT_HOME / conf / [Engine] / [Host] /.
  3. Maintenant, le fichier “$ APP_NAME.xml” que nous venons de créer doit avoir une définition du contexte et des parameters + Any EnvironmentVariable que vous voulez spécifique à ce contexte.

Par exemple, j’ai une application Web appelée VirtualWebApp.

Je vais créer un fichier comme VirtualWebApp.xml avec une définition de contexte ci-dessous:

     

Pour accéder à ces variables d’environnement, vous devez écrire ci-dessous le code (Just lookup):

 InitialContext initialContext = new javax.naming.InitialContext(); host = (Ssortingng)initialContext.lookup("java:comp/env/webservice.host"); port = (Ssortingng)initialContext.lookup("java:comp/env/webservice.port"); 

En vous référant à la documentation Apache Tomcat 5.5 :

Dans le fichier $ CATALINA_HOME / conf / context.xml: les informations de l’élément de contexte seront chargées par toutes les applications Web

Vous pourriez facilement essayer cette approche, cela pourrait fonctionner, mais je ne suis pas sûr que ce soit une bonne solution, surtout si vous exécutez plusieurs applications Web sur Tomcat.

Je ne sais pas comment modifier le comportement de Tomcat mais je pourrais penser à 2 solutions différentes:

  1. des scripts de génération différents (paramétrés) pour chaque environnement, de sorte que vous définissiez un paramètre appelé env pour vos scripts de construction et, en fonction de la valeur, il place l’environnement context.xml spécifique à l’environnement dans votre WAR lors de la construction.
  2. Créez un script d’ install pour chaque environnement qui redéploie d’abord le fichier WAR (le place dans le répertoire webapps ), puis modifie l’installation de Tomcat en fonction de l’environnement, par exemple, nom d’hôte différent pour JDBC DataSource dans context.xml .

J’utilise beaucoup cette dernière approche car elle fonctionne dans les environnements d’entreprise. Les règles de séparation des tâches interdisent souvent à l’équipe de développement de connaître, par exemple, les mots de passe de la firebase database de production. L’option 2 résout ce problème car seules les opérations informatiques ont access aux scripts d’installation spécifiques à l’environnement après leur création.

@ n0rm1e: je ne suis pas sûr que tomcat offre une solution à votre problème. Mais une solution possible peut être: – créer un script ant avec les étapes suivantes:

i) Vérifiez l’existence du fichier .xml dans le répertoire [nom-moteur] / [nom-serveur]. S’il existe, sauvegardez-le / renommez-le.

ii) copiez votre fichier war sur les applications Web tomcat. Redémarrez le serveur Tomcat.

iii) recopie le fichier de configuration de sauvegarde dans le répertoire [nom-moteur] / [nom-serveur]