11
votes

Comment définir le chemin de contexte dans Tomcat afin que l'on puisse entrer dans le site sans ajouter le nom du dossier déployé?

J'ai lu à ce sujet sur ce guide Tomcat ici et certaines questions. Et je pense que je fais à peu près la même chose. Mais d'une manière ou d'une autre ne peut pas réussir à réussir.

Tout d'abord, je dois dire que ma demande est déployée sur un serveur Tomcat partagé que je n'ai aucun contrôle. Je viens de laisser tomber mon fichier .war et il est déployé.

J'ai essayé d'emballer mon application comme root.war mais n'a pas fonctionné. L'administrateur m'a dit de l'emballer comme quel que soit le nom que je veux et qu'ils s'en occuperaient. Je l'ai emballé comme mon-application.war et il a été déployé mais je dois entrer http: // My-Host / My-Demande Pour accéder au site Web.

Après avoir contacté l'administrateur, ils m'ont dit qu'ils ont mis un contexte Elemnt dans mon hôte dans mon hôte dans le fichier de configuration Tomcat comme: xxx

qui était censé se mettre My-Demande comme application par défaut pour toutes les demandes qui arrivent sur My-Host . Mais ce n'est pas et chaque fois que j'entre http: // My-Host < / em> je reçois: xxx

mais à nouveau lorsque j'entre http: // My-Host / My-Demande Tout fonctionne bien. Toute suggestion sur ce qui pourrait être faux est définitivement apprécié.

mises à jour:

J'ai essayé de suivre les étapes décrites dans Tomcat Documentation sur Comment faire de l'application par défaut . 3 voies sont décrites et j'ai essayé les trois manières de déployer avec succès ma candidature en tant que root sur localhost.

J'ai également essayé de reproduire le problème que je suis confronté sur le serveur distant afin que je puisse trouver la raison et le signaler à l'administrateur. Je trouve quelques problèmes.

  1. dans gréseur.xml fragment que l'administrateur m'a envoyé autodétode et de DeployOnstartup sont définis sur true, alors qu'ils devraient être faux si défini explicitement le contexte élément in server.xml. Cela provoquera un double déploiement qui crée un dossier racine et un dossier avec le nom du fichier .war. La suppression de la .war supprimera que le dossier correspondant et n'entroie pas l'application, mais la racine reste effacée et doit être supprimée manuellement et nécessite un redémarrage de Tomcat. Jusqu'à ce qu'il soit redémarré de tout déploiement de root.war échouera.
  2. J'ai pensé qu'il y a des raisons d'empêcher la racine.war du déploiement. On pourrait être qu'un root.xml existe dans conf / {nom-nom du moteur} / {hôte-nom} ou un dossier racine existe dans l'appbase de l'hôte ou comme je l'ai décrit ci-dessus une application racine du déploiement précédent n'est pas non téléchargée et nécessite un redémarrage de Tomcat.

    de toute façon, je ne pouvais pas préciser exactement ce qu'est exactement empêchant la racine.war du déploiement car cela nécessite l'accès aux fichiers journaux Tomcat et à des fichiers Conf pour vérifier les cas que j'ai décrits ci-dessus.

    De plus, je vois que mon administrateur semble incapable de maintenir un serveur Tomcat et de trouver le problème. J'ai donc décidé d'aller avec un serveur Tomcat dédié après avoir lu avec le partagé.


4 commentaires

Tomcat est-il utilisé autonome et servant HTTP ou existe-t-il une autre manipulation de serveur qui et communiquant à Tomcat via AJP? On dirait que des hébergements virtuels se passent. Est-ce que c'est défini dans le principal server.xml ou effectué en tant que fichier de configuration spécifique d'hôte distinct sous conf / catalina ?


Je viens d'essayer d'ajouter le chemin de contexte sur mon fichier Server.xml de Tomcat et il a fait la redirection comme un champion. Tout ce que j'ai fait a été mis Docbase = "My-Demande" et non un chemin absolu ou quoi que ce soit comme ça. Dans votre exemple de code ci-dessus, c'est ce que "chemin du dossier déployé de mon application" signifie?


Aussi, avez-vous accès à l'ensemble de l'élément qui contient l'élément ? En fonction de ses paramètres, cela peut empêcher les paramètres de contexte de travailler comme si vous vous attendez.


@Jeffgoldberg Le chemin ci-dessus est absolu. Je n'ai pas accès à élément mais je l'ai vu et il a ses attributs par défaut. À l'intérieur, il n'y a que l'élément que j'ai décrit ci-dessus. Je vais essayer de demander à l'administrateur de lui donner un chemin relatif à la place.


3 Réponses :


4
votes

généralement, cela peut être obtenu par les étapes suivantes:

  • Définissez un fichier de contexte root.xml dans Conf / Catalina / localhost
  • Nom de votre webApp War "root.war" ou contenant du dossier "root"

    Cependant, je doute que vous puissiez le faire sur une instance de Tomcat partagée. Une seule application peut exécuter comme application par défaut. La société d'hébergement ne l'autorisera probablement pas comme une autre quelle application permettra-t-elle d'être la valeur par défaut des nombreuses personnes partageant la même instance Tomcat?

    Voir ce lien: http: // staraphd.blogspot.com/2009/10/Change-default-root-folder-in-tomcat.html


3 commentaires

Merci pour la référence. Mais je n'ai pas le contrôle de la plupart des parties que l'article suggère. Et je pense que l'administrateur a déjà défini le contexte de la partie tel que je l'ai mentionné.


Si l'administrateur a défini votre chemin de contexte ... Il y a votre réponse, vous ne pouvez pas le faire sans que l'utilisateur est entré dans un "dossier" comme http // myapp.com / myApp. La seule façon de passer en avant, c'est pour obtenir l'administrateur de vous déplacer en tant que root.war ou faire pointer votre guerre de la racine.xml.


@Bob selon ici La méthode que j'ai décrite ci-dessus est censée définir l'application par défaut. Bien que cela ne soit pas clair sur ceci, qu'il remplace l'application racine et devient la nouvelle racine ou qu'elle agit comme défaut pour les applications non attribuées à la racine et à tout autre contexte déjà défini que ce dernier n'a pas de sens que je pense que je pense que je pense que .



3
votes

Le Tomcat wiki a un section sur mettre les applications dans le contexte par défaut. Cependant, afin de le faire, cela implique un certain contrôle sur le serveur Tomcat qui peut ne pas être possible dans le contexte partagé que vous décrivez.

Si vous avez la possibilité d'installer d'autres systèmes sur le serveur, une solution alternative serait d'utiliser un serveur proxy comme Nginx. Ceci est beaucoup plus compliqué que simplement nommer la racine de votre fichier de guerre.war, mais parfois c'est la seule option.

Si vous avez une écoute NGinx sur le serveur et que vous avez votre propre URL, vous utilisez votre propre URL, vous utilisez la httpproxymodule avec réglage tel que: xxx

aussi afin de faire Ce travail, vous auriez à posséder l'URL "My.Domain.com" et Il faudrait être séparé de celui que tout le monde utilise pour le serveur Tomcat partagé.

La partie Nginx de la solution est gratuite, mais si vous devez enregistrer une nouvelle URL, puis utilisez quelque chose comme no-ip.com pour la rediriger vers le serveur Tomcat, il coûterait de l'argent.


3 commentaires

Je pense que je préfère rester en configuration de Tomcat pour obtenir les résultats. Merci quand même.


Oui, j'ai pensé. Cette solution est vraiment plus pour un scénario où vous avez beaucoup de sites et beaucoup d'URL à rediriger. Mais je pensais que cela pourrait être utile à quelqu'un.


Cela a fonctionné pour moi. Merci pour le conseil. J'ai été vraiment ennuyé par le "contexte" de chaque application à la fin de l'URL.



6
votes

Dans votre question, vous affirmez que l'administrateur définit le contexte comme suit:

<Context path="/" docBase="my-application/" />


3 commentaires

J'ai essayé avec un chemin relatif juste au cas où les chemins absolus de appbase et Docbase ont des conflits, mais ce n'était pas le problème qu'il semble.


Tu m'as sauvé beaucoup de temps. Merci beaucoup.


J'ai essayé de donner un chemin relatif au lieu de donner un chemin absolu, mais le serveur Tomcat n'exécutait pas ..