Pourquoi Tomcat aime-t-il supprimer mon fichier context.xml?


24

Je développe une application Java basée sur le Web au travail et (évidemment) je dois l'exécuter localement pendant le développement. J'ai compris les documents Tomcat et j'ai un fichier context.xml approprié /etc/tomcat6/Catalina/localhost/mais de temps en temps, Tomcat décide de le supprimer! Ce qui signifie que je dois le remettre et redémarrer Tomcat.

Pourquoi fait-il ça? J'ai cherché dans les documents Tomcat à ce sujet et je ne suis pas plus sage.

(Oh oui: ce n'est pas réellement appelé context.xmlmais owners.xmlcomme c'est le préfixe du chemin HTTP pour cette application.)

Mise à jour

J'ai maintenant vu Tomcat supprimer le fichier pendant que Tomcat était en cours d'exécution . Je pense que je dois déposer un bug ...


Avoir ce problème. On dirait que lorsque vous remplacez votre guerre, cela provoque le déploiement de l'application qui entraîne la suppression du fichier de contexte. Je n'ai pas de
solution de

Réponses:


18

Résumé rapide : il existe plusieurs conditions (comme changer le fichier war, supprimer la webapp ou la remplacer par un nouveau contenu) dans lesquelles tomcat annulera le déploiement du contexte, y compris la suppression du fichier de contexte.

Détails : si tomcat fait ou non le déploiement automatique (cela signifie vérifier les changements dans votre descripteur .xml ainsi que vérifier les changements dans le répertoire webapp) est déterminé par:

  1. server.xml localisé dans la section $ CATALINA_HOME / conf / server.xml:

    <Nom d'hôte = "localhost" appBase = "webapps" unpackWARs = "true" autoDeploy = "true" xmlValidation = "false" xmlNamespaceAware = "false">

  2. Vous pouvez également définir cette propriété dans votre fichier de contexte en surchargeant la valeur

La citation du document pour les cas où autoDeploy = true peut entraîner la suppression de votre fichier de contexte:

  • La suppression d'un fichier WAR déclenchera le retrait de l'application avec la suppression de tout répertoire étendu, fichier de contexte et répertoire de travail associé .
  • La suppression d'un répertoire déclenchera un retrait de l'application avec la suppression de tout fichier de contexte et répertoire de travail associé .
  • La mise à jour d'un fichier WAR déclenchera un retrait de l'application avec la suppression de tout répertoire étendu, fichier de contexte et répertoire de travail associé .
  • La mise à jour d'un répertoire (et non du contenu du répertoire) déclenchera un retrait de l'application avec la suppression de tout fichier de contexte et répertoire de travail associé .

Détails exhaustifs : http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Automatic%20Application%20Deployment


Ce n'est pas une réponse complète - voir serverfault.com/faq#deletion
Jenny D dit Reinstate Monica

:) s'il vous plaît, aidez-vous (la mise en évidence de la syntaxe semble légèrement différente de celle de stackoverflow qui a supprimé une partie de la réponse auparavant)
Jan Zyka

Le fait est que si vous ajoutez simplement un lien, la cible du lien peut disparaître, rendant la réponse inutile. C'est pourquoi serverfault.com vous encourage à publier la réponse réelle au lieu du simple lien. Et quand j'ai commenté, le reste du texte n'était pas visible. Je recommanderais toujours de publier une réponse plus complète plutôt qu'un bref résumé du lien.
Jenny D dit Réintégrer Monica le

1
Ce n'est tout simplement pas vrai. La réponse originale contenait (et contient toujours) un bref résumé de ce que vous pouvez trouver sous le lien. Sans le lien, la réponse reste parfaitement logique et avec le lien, vous pouvez trouver des détails.
Jan Zyka

Mais je n'avais pas prévu d'être offensant, donc désolé si ça sonnait comme ça :) Je ne suis pas beaucoup dans ce web, je résolvais juste la même chose et je voulais partager.
Jan Zyka

5

Si vous ne voulez pas la fonction autoDeploy , dans les environnements de production par exemple, vous pouvez considérer les attributs suivants dans le fichier de contexte conf / Catalina / localhost:

  • autoDeploy = "false"
  • et deployXML = "false"

autoDeploy = "false" peut ne pas fonctionner seul car l'application context.xml (dans META-INF) peut remplacer les paramètres server.xml de autoDeploy.

  • Le META-INF / context.xml de l'application sera utilisé dans l'environnement de développement, avec autoDeploy
  • Le contexte conf / Catalina / localhost en production, sans autoDeploy.

documentation d' attribut deployXML La documentation d' attribut vaut la peine d'être lue (§ Implémentation standard).

Cas utilisateur exhaustif autoDeploy, et lorsque le contexte est supprimé: c'est-à-dire que l'application n'est pas déployée, le cas utilisateur est documenté peut être trouvé ici .


2

Je ne peux pas répondre au pourquoi .

Cependant, ce lien indique que vous pouvez arrêter ce en définissant le autoDeploy="false"dansserver.xml


1
Sous tomcat7, autoDeploy = "false" ne fait aucune différence :(
Joseph Lust

1

Honnêtement, je ne sais pas quel est le raisonnement derrière Tomcat, mais essayez d'ajouter l'attribut XML suivant à votre élément de contexte

reloadable="false"

Votre contexte pourrait donc ressembler à ceci:

<Context path="/" docBase="/some/path/name" reloadable="false">
<!-- Context related stuff -->
</Context>

Cela devrait empêcher Tomcat de supprimer le fichier


Malheureusement, cela rend le développement plus difficile car je devrais redémarrer Tomcat après chaque build.
staticsan

consultez jrebel pour aider à cela dans le développement: zeroturnaround.com/jrebel
harmanjd

0

Je me rends compte que c'est un vieux fil, mais j'ai pensé partager ce que j'ai trouvé pour résoudre ce problème ...

J'avais eu exactement le même problème avec mon fichier context.xml pour ma version de bureau de tomcat qui était encombré chaque fois que je déployais une nouvelle copie du fichier war pour mon application.

Le problème était dû au fait que j'apportais des modifications à ce fichier directement sur le système de fichiers. Ce qui a résolu le problème était d'éditer le fichier context.xml via mon éditeur Eclipse. À l'intérieur de mon Eclipse, il y a un projet "serveurs" qui une fois que vous l'avez développé, vous pouvez voir une poignée de fichiers, tels que context.xml et server.xml. Il semble que si vous modifiez les fichiers à partir d'ici au lieu d'aller vers le système de fichiers, vos modifications sont conservées.

J'ai trouvé cette solution dans le fil suivant: https://www.liferay.com/community/forums/-/message_boards/message/16511799

J'espère que ça aidera quelqu'un d'autre!

-StephenS


0

Le problème général tel que décrit par le titre est couvert par Redéployer après la guerre sans supprimer le contexte qui est toujours un problème ouvert pour le moment.

Il existe une distinction reconnue entre le redéploiement qui ne supprime pas le contexte et le déploiement après le non-déploiement où le non-déploiement supprime le contexte. La documentation était obsolète et l'interface graphique du gestionnaire ne prend toujours pas en charge le redéploiement.


-1

Parfois, il est nécessaire d'avoir des valeurs différentes pour l'application sur le serveur, par exemple un chemin pour stocker les fichiers téléchargés. Dans l'environnement de développement mabe, nous avons quelque chose comme ceci:

<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" reloadable="false">
     <Parameter name="rutaTrabajo" value="C:\Larry\Proyectos\app\rutaTrabajoxx" override="true"/>
</Context>

Mais dans le serveur, le chemin est différent:

<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" >
     <Parameter name="rutaTrabajo" value="/usr/share/App/rutaTrabajo" override="true"/>
</Context>

J'ai également le même problème, tomcat supprimant le context.xml (meapp.xml) de conf / Catalina / localhost

Pour résoudre, j'utilise context.xml.default, dans le même chemin, je crée un fichier appelé context.xml.default et à l'intérieur d'une configuration de mise que je souhaite conserver:

 cat context.xml.default
<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" >
     <Parameter name="rutaTrabajo" value="/usr/share/ParkiMeApp/rutaTrabajo" override="true"/>
</Context>

Ainsi, lors du redéploiement de l'application, les paramètres de confir sont toujours là.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.