Gestion des références de chemin de contexte lors de la migration du site "/" vers un package Java EE

Un site Java existant est conçu pour s'exécuter sous "/" sur tomcat et de nombreuses références spécifiques aux chemins absolus fixes tels que "/ dir/dir/page ". Voulez-vous migrer vers un package Java EE, où le site devra s'exécuter sous une racine de contexte, par ex. "/ dir/dir/page" devient "/ mon-contexte-racine/dir/dir/page"Gestion des références de chemin de contexte lors de la migration du site "/" vers un package Java EE

Maintenant, la racine de contexte peut être facilement avec ServletRequest.getContextPath(), mais cela signifie encore beaucoup de modifications de code pour migrer une base de code importante. La plupart de ces références sont en HTML littéral.

J'ai expérimenté l'utilisation de filtres de servlets pour faire des réécritures sur le HTML sortant, et cela semble fonctionner correctement. Mais cela introduit des frais généraux, et je ne verrais pas cela comme une solution permanente. (Voir EnforceContextRootFilter-1.0-src.zip pour l'approche du filtre de servlet).

Y a-t-il de meilleures approches pour résoudre ce problème? Quelque chose d'évident me manque? Tous les commentaires ont apprécié!

Source

2008-09-27 tardate

Je me rends compte peut-être l'évidence, mais les applications JavaEE peuvent encore être déployés dans le contexte racine (/). Cette configuration est généralement gérée dans un fichier de déploiement spécifique à un serveur d'applications (par exemple, jboss-web.xml, sun-web.xml). –

@jt bon point, et j'ai demandé si je manquais quelque chose d'évident ;-) Dans mon cas, j'ai besoin de l'application à déployer avec d'autres applications sur le même serveur, et ne peut pas monopoliser le contexte racine (et aussi acceptable pour fonctionner sur un autre hôte virtuel). – tardate

extrayez un lié question

Voir également URLRewriteFilter

Une autre chose (je continue à éditer ce post darn). Si vous utilisez JSP (par opposition à du HTML statique ou autre), vous pouvez également créer un fichier de variables pour remplacer les balises html courantes par des liens (notamment a, img, form). Donc < un lien href = "/ root/path"> </a> peut devenir < t: un lien href = "/ root/path"> </t: a>. Ensuite, le tag peut faire la traduction pour vous.

Ce changement peut être facilement fait "en masse", en utilisant quelque chose comme sed. Les actions de formulaire peuvent être un peu plus compliquées que sed, mais vous en avez l'idée.

Source

2008-09-27 06:41:44

@will merci pour le x-ref. J'ai effectivement posté là et prop'd votre réponse.J'ai bifurqué cette question pour adresser spécifiquement la migration de code existant, tandis que l'autre q est vraiment sur la gestion des contextes de meilleure pratique dans le code que je construis je pense que – tardate

URLRewriteFilter a des capacités de règles entrantes très flexibles, mais le mappage sortant est actuellement limité aux URL de réécriture via response.encodeURL(). – tardate

Le monde apache utilisé Redirige (mod_rewrite) pour faire de même.

Le monde Servlet a commencé à utiliser les filtres

Le monde du rubis (ou RoR) fait plus de la même chose et ils l'appellent le routage. Donc, il n'y a pas moyen de contourner cela (sauf si vous voulez utiliser smart regex à travers - ce qui a été essayé et cela fonctionne très bien).

Source

2008-09-27 06:17:41 anjanb

apache réécrit peut être utilisé dans le cas également, mais je préfère l'approche de filtrage car il est local à l'application spécifique. S'assurer que la réécriture d'Apache ne gâchera pas d'autres applications déployées, je pense, serait difficile si vous avez beaucoup déployé sur le même serveur. – tardate

btw, oui je suis un grand fan de routage dans les rails. C'est la façon dont les URL devraient toujours avoir été gérées, mais malheureusement le monde java a commencé un chemin différent il y a longtemps ;-) – tardate

Gestion des références de chemin de contexte lors de la migration du site "/" vers un package Java EE

Répondre

Questions connexes