CATALINA_HOME contre CATALINA_BASE

Je ne trouve pas de réponse définitive à la raison pour laquelle Ubuntu définirait la CATALINA_BASEvariable d'environnement, la rendant différente de CATALINA_HOME. J'ai trouvé ce document qui suggère que le fait de ne pas le définir CATALINA_BASEle rendrait équivalent à CATALINA_HOME. Ce document suggère également que la configuration CATALINA_BASEserait effectuée pour rendre plusieurs instances disponibles.

Cependant, je ne semble pas pouvoir trouver quoi que ce soit qui explique cela. Vraisemblablement, courir avec un single CATALINA_HOMEa été bon pendant longtemps, mais Ubuntu est passé.

Je trouve cette question avec une réponse éclairante sur AskUbuntu mais il n'y a pas grand - chose spécifiquement CATALINA_HOMEcontre CATALINA_BASE. Cette question fait allusion au paramètre "appBase", qui est documenté dans la documentation Tomcat6 pour le conteneur Host dans le fichier de configuration.

Voici les questions: pourquoi ces deux variables sont-elles séparées? Quand devraient-ils être séparés? Qu'est-ce que cela permet à l'administrateur de faire? Que placez-vous ensuite dans chaque répertoire? Quand ces deux variables doivent-elles être identiques? Que recommande ASF pour la pratique standard?

Pourquoi ces deux variables sont-elles séparées?

catalina.home indique l'emplacement des informations communes.
catalina.base pointe vers le répertoire où se trouvent toutes les informations spécifiques à l' instance .

Vous avez donc 1 domicile et pouvez avoir plus d'une base.

Quand devraient-ils être séparés? Quand ces deux variables doivent-elles être identiques?

Si vous avez 1 tomcat, vous pouvez leur attribuer la même valeur, mais les bonnes pratiques suggèrent de planifier à l'avance et de les séparer: vous ne savez jamais si vous avez besoin de plus d'un tomcat. Ubuntu a commencé à suivre cette façon de penser car il est plus logique: il facilite l'exécution de 2+ tomcats mais ne désactive pas l'exécution de 1 tomcat où les mettre tous les deux à la même valeur obligerait tout le monde à modifier la valeur de base. Il est plus logique de les garder différents.

Qu'est-ce que cela permet à l'administrateur de faire?

Autorisez l'exécution de plus d'un tomcat en même temps, chaque instance de tomcat pouvant avoir ses propres applications.

Que placez-vous ensuite dans chaque répertoire?

La maison contient le binairy.
La base contient conf, logs, webapps, work et temp. 1 pour chaque instance de tomcat.

CATALINA_HOME contre CATALINA_BASE

Si vous exécutez plusieurs instances, vous avez besoin des deux variables, sinon uniquement CATALINA_HOME.

En d'autres termes: CATALINA_HOMEest obligatoire et CATALINA_BASEfacultatif.

CATALINA_HOME représente la racine de votre installation Tomcat.

Facultativement, Tomcat peut être configuré pour plusieurs instances en définissant $CATALINA_BASEpour chaque instance. Si plusieurs instances ne sont pas configurées, $CATALINA_BASEest identique à $CATALINA_HOME.

Voir: Apache Tomcat 7 - Introduction

Fonctionnant avec séparé CATALINA_HOMEet CATALINA_BASEdocumenté dans RUNNING.txt qui dit:

Les variables d'environnement CATALINA_HOMEet CATALINA_BASEsont utilisées pour spécifier l'emplacement d'Apache Tomcat et l'emplacement de sa configuration active, respectivement.

Vous ne pouvez pas configurer les variables CATALINA_HOMEet CATALINA_BASEdans le setenvscript, car elles sont utilisées pour rechercher ce fichier.

Par exemple:

(4.1) Tomcat peut être démarré en exécutant l'une des commandes suivantes:

  %CATALINA_HOME%\bin\startup.bat         (Windows)

  $CATALINA_HOME/bin/startup.sh           (Unix)

ou

  %CATALINA_HOME%\bin\catalina.bat start  (Windows)

  $CATALINA_HOME/bin/catalina.sh start    (Unix)

Plusieurs instances Tomcat

Dans de nombreuses circonstances, il est souhaitable d'avoir une seule copie d'une distribution binaire Tomcat partagée entre plusieurs utilisateurs sur le même serveur. Pour rendre cela possible, vous pouvez définir la CATALINA_BASE variable d'environnement dans le répertoire qui contient les fichiers de votre instance Tomcat «personnelle».

Lors de l'exécution avec un CATALINA_HOMEet séparé CATALINA_BASE, les fichiers et répertoires sont divisés comme suit:

Dans CATALINA_BASE:

• bin - Uniquement: setenv.sh (* nix) ou setenv.bat (Windows), tomcat-juli.jar
• conf - Fichiers de configuration du serveur (dont server.xml)
• lib - Bibliothèques et classes, comme expliqué ci-dessous
• logs - Fichiers journaux et de sortie
• webapps - Applications Web chargées automatiquement
• work - Répertoires de travail temporaires pour les applications Web
• temp - Répertoire utilisé par la JVM pour les fichiers temporaires>

Dans CATALINA_HOME:

• bin - Scripts de démarrage et d'arrêt
• lib - Bibliothèques et classes, comme expliqué ci-dessous
• endorsed- Bibliothèques qui remplacent la norme "Normes approuvées". Par défaut, il est absent.

Comment vérifier

La façon la plus simple de vérifier ce qui vous appartient CATALINA_BASEet CATALINA_HOMEde l'exécuter est d'exécuter startup.sh, par exemple:

$ /usr/share/tomcat7/bin/startup.sh
Using CATALINA_BASE:   /usr/share/tomcat7
Using CATALINA_HOME:   /usr/share/tomcat7

Vous pouvez également vérifier où les fichiers Tomcat sont installés, par l' dpkgoutil ci-dessous (Debian / Ubuntu):

dpkg -L tomcat7-common

En plus d'être le meilleur moyen d'exécuter deux instances de tomcat, il facilite la mise à jour.

J'utilise cette configuration.

<!-- language: bash -->

/opt/apache-tomcat-7.0-32
/opt/apache-tomcat-7.0.39
/opt/apache-tomcat-7       (simbolic link to apache-tomcat-7.0.32)

CATALINA_HOME = / opt / apache-tomcat-7

/srv/user_deploys/tomcat_product_a
/srv/user_deploys/tomcat_product_b

CATALINA_BASE pointe vers l'un ou l'autre répertoire de déploiement.

Les binaires et bibliothèques de base sont sur /opt/Just copy server.xml, web.xml(et certains autres fichiers, lisez les docs, s'il vous plaît) et créez des répertoires bin, logs, webapps, temp, work (RTLM, L as lovelly, please)

Vous pouvez mettre à jour les binaires tomcat, en modifiant CATALINA_HOMEle fichier $ CATALINA_BASE / bin / setenv.sh pour chaque instance ou vous pouvez simplement modifier le lien symbolique, en mettant à jour les binaires "globalement"

Il est plus facile de mettre à jour même si vous n'avez qu'une seule instance.