Modification de l'application Web Tomcat contexte

Question

J'ai une application web, qui a été conçu et a toujours travaillé dans le contexte racine ("/"). Donc, tous les css, js et liens a commencé avec / (par exemple /css/style.css). Maintenant, je dois déplacer cette application web dans un contexte différent (disons /app1). Il est facile de changer le fichier de configuration server.xml et mettre en place l'application Web dans le nouveau contexte app1 utilisant [Context path=""] article. Mais les pages Web sont cassées parce que tous les liens sont maintenant incorrects. Ils pointent vers l'ancien contexte racine /css/style.css au lieu du nouveau contexte app1. Y at-il un moyen magique de résoudre ce problème sans réparer chaque lien en préfixant avec une variable "contexte"? Serveur utilisé - Tomcat 5. L'application est écrite avec Java et utilise le filtre JSP, Struts2, Spring et UrlRewrite. Plus intéressant est d'entendre une expérience réelle dans la lutte contre de tels problèmes que les débats théoriques. Merci.

P.S. Je ne vois pas comment le filtre UrlRewrite peut m'aider car il ne fonctionnera que dans le contexte app1. Ainsi, les demandes de liens comme /css/style.css ne lui seront pas transmises.

Answer 1

Vous devez toujours créer des URL via la réécriture d'url, pas seulement pour que l'information de session puisse être ajoutée à la url, si nécessaire, mais aussi pour que le chemin du contexte puisse être ajouté. Vous devez créer toutes les urls comme des chemins absolus depuis le haut de l'application, puis laisser l'url-rewriting gérer l'ajout du chemin de contexte au front, selon le cas.

<c:url value="/css/site.css"/> 

Cela rendra dans un fichier jsp /<context-path>/css/site.css ou /<context-path>/css/site.css;jsessionid=134345434543 si elles ne sont pas les cookies. Vous pouvez également utiliser la balise c: url pour afficher l'URL dans une variable, puis l'utiliser plusieurs fois dans votre document. Ajoutez simplement un attribut var="x" à l'étiquette, puis ${x} affichera l'URL dans votre document. Si vous n'utilisez pas jsp pour rendre votre sortie, vous devrez trouver le mécanisme approprié pour votre couche d'affichage, mais ils en auront tous un. Si vous affichez une URL dans un code java, jetez un oeil au code source de la balise c: url et vous verrez comment cela se fait. Le seul inconvénient est que les fichiers CSS (et les fichiers js) ne sont pas traités, donc les urls dans les fichiers css et js doivent être des chemins relatifs ou ils se casseront à chaque fois que vous changerez le chemin du contexte. La plupart des js utilisent déjà des chemins relatifs car les mainteneurs de bibliothèques ne savent pas dans quel chemin vous allez installer leur bibliothèque. D'autre part, les images de backround CSS sont souvent spécifiées comme des URL absolues, puisque le même fichier CSS peut être inclus dans des fichiers html à différents niveaux d'une hiérarchie de fichiers. Il n'y a pas de solution facile à cela que je connaisse autre que de créer des liens symboliques appropriés tels que l'URL relative fonctionne toujours ou bien servir les fichiers CSS problématiques via une JSP afin que les URL puissent être réécrites comme il convient. Je suis sûr qu'il y a probablement des filtres ou des modules Apache que vous pouvez utiliser pour faire le remplacement de l'url, mais vous devez quand même mettre à jour manuellement votre filtre/module chaque fois que vous déployez sur un nouveau chemin de contexte.

Answer 2

Si vous utilisez la réécriture d'URL pour rediriger ROOT à votre demande, ne sera pas que d'éliminer la possibilité d'avoir une application dans ROOT? Si oui, que gagne-t-on en changeant de contexte?

Je pense que la manière générale de lier les ressources est soit ajouter une variable « contexte » et faire le lien absolu: ${pagecontext.request.contextpath}/css/style.css ou tout simplement faire le lien relatif: css/style.css

Sauf si vous avez des raisons spécifiques pour être incapable de modifier le code, je ferais une recherche/remplacer sur les liens et être fait avec lui. Vous ne devriez pas avoir plus de trois ou quatre expressions à trouver,/css,/images,/javascript, etc.