2010-07-27 3 views
0

J'ai une application struts2 s'exécutant sous un chemin de contexte "/ path" sur mon tomcat local sans problèmes. Lorsque je le déploie sur un serveur web (en utilisant un proxy pour rediriger de "http://www.domain.com" vers "myserver: 8080/path /") Struts fait toutes sortes de choses étranges. D'abord, il inclut le contexte dans -tags. Cela peut être désactivé par un attribut. Mais malheureusement, il comprend également le chemin dans les attributs d'action de mes formes, donc un formulaire de connexion pointe vers "http://www.domain.com/path/login.action" au lieu de "http://www.domain.com/login.action" ...Déploiement de Struts2 Application sans ContextPath

Y at-il une possibilité de changer en quelque sorte le contexte par défaut qui est ajouté ici ou désactiver cela pour les formulaires? (Je voudrais garder les -tags, seul moyen semble être d'utiliser les formulaires HTML par défaut.) Merci d'avance!

+0

J'ai fait quelques tests et je pense que vous devrez utiliser l'élément de formulaire HTML par défaut et définir l'action avec la balise ''. La chose étrange est que les documents WebWork (https://cwiki.apache.org/WW/form.html) montrent un paramètre includeContext sur la balise ''. C'est la première fois que je vois un comportement manquant de Struts2 dans WebWork. – Pat

+0

Hé là! Merci pour votre réponse. Malheureusement, l'attribut d'action du ne prend pas un . Seule solution de contournement semble ne pas utiliser la balise s: form - que je ne veux pas. – Akku

+0

L'utilisation de includeContext = "false" ne change rien non plus. – Akku

Répondre

0

J'ai trouvé que d'autres avaient aussi le problème, mais les décideurs ne semblent pas penser que c'est un problème. Mes solutions:

  • utilisation includeContext = "false" dans toute s: url-tags
  • au lieu des s: balise form, utilisez une forme habituelle, définir l'action à "actionname.action" et inclure une table simple avec tablerows() pour chaque champ. Vous pouvez toujours utiliser s: textfield et autres. Malheureusement, les sessions HTTP ne fonctionneront plus car elles sont définies pour le chemin "/ path" (le chemin d'application). Cela est dû au cookie qui enregistre le JSESSIONID défini sur/path. Cela signifie que vos visiteurs ne verront que les variables de session stockées lorsqu'elles seront au http://www.domain.com/path/login.action et qu'elles seront perdues lorsqu'elles seront redirigées vers http://www.domain.com/interestingstuff.action ... ma solution est un hack qui nécessite de paramétrer le cookie JSESSIONID clientide via JavaScript comme décrit ici : Struts2: Session Problem (after reverse proxy)

Espérons que cela aide quelqu'un ... si vous trouvez des solutions plus agréables, s'il vous plaît faites le moi savoir. :-)

0

Bien que je réponde très tard à cette question, mais j'ai atteint cette page récemment quand je faisais face au même problème.

L'application sur laquelle je travaillais était en train d'ajouter le context-root viz. 'myContextRoot' à mon URL sur localhost et ça fonctionnait parfaitement. Par exemple, comme mentionné ci-dessus, l'action 'myAction' devenait http://localhost:8050/myContextRoot/myAction.action Mais au moment où je l'ai déployé sur un serveur, il a cessé de fonctionner, puis après avoir cherché l'enfer, j'ai trouvé une solution pour moi. Je déploie un fichier EAR sur glassfish et nous avons un fichier application.xml. En application.xml j'avais une étiquette « contexte racine » dont la valeur était « myContextRoot » que je changé pour «/» et après que je suis arrivé mon URL comme sur localhost et

L'espoir peut aider :)

Questions connexes