IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Struts 1 Java Discussion :

[webapp][struts] Répertoires virtuels dans l'URL


Sujet :

Struts 1 Java

  1. #1
    Membre à l'essai
    Inscrit en
    Juin 2002
    Messages
    13
    Détails du profil
    Informations forums :
    Inscription : Juin 2002
    Messages : 13
    Points : 12
    Points
    12
    Par défaut [webapp][struts] Répertoires virtuels dans l'URL
    Bonjour,

    Soit une webapp accessible à l'adresse http://serveur:8080/appli/
    Afin de pouvoir personnaliser l'interface tout en conservant une URL simple et attractive, je souhaiterais distinguer mes clients en incluant leur nom directement dans l'URL. Exemples :
    http://serveur:8080/appli/client1/
    http://serveur:8080/appli/client2/
    etc...

    Bien entendu l'application derrière est identique, et donc /client1/login.do et /client2/login.do appellent la même action.
    Seulement voilà, je ne suis pas parvenu à le faire fonctionner, et j'espère que vous pourrez m'y aider.

    J'utilise Tomcat 5.5 et j'aimerais pouvoir me passer de httpd (mod-rewrite constitue sans doute une solution mais je préfèrerais gérer ça directement sous Tomcat). Dupliquer la webapp pour chaque client n'est pas envisageable (pour des questions de ressources, mais aussi parce que la liste des clients est dynamique et stockée en base).

    J'ai essayé de modifier le mapping de l'ActionServlet de Struts, mais cela ne fonctionne pas. Avec <url-pattern>*.do</url-pattern> (par défaut) il m'envoie une erreur 404 quand je tape par exemple http://serveur:8080/appli/client1/login.do
    J'ai aussi essayé, sans succès, <url-pattern>/*/*.do</url-pattern> (là il me dit carrément que le mapping est incorrect).
    J'ai ensuite cherché à inverser les deux, pour construire une URL du type http://serveur:8080/appli/login.do/client1/ , ce qui constitue une URL moins "jolie" mais encore acceptable par rapport à ce que je veux faire. Je m'attendais à ce que la partie de l'URL après le .do soit transmis comme paramètre de la requête. Un peu comme ce que permet de faire l'option MultiViews sous httpd, mais sous Tomcat. Mais là aussi, échec (404).

    De plus, il me reste le problème du mapping des autres types d'objets (jsp, images, etc...) sous ces mêmes répertoires "virtuels" (faut-il pour cela modifier le mapping des servlets default et jsp ? Si oui, peut-on le faire dans le web.xml de l'application afin que tout soit déployé dans le WAR final, ou faut-il impérativement modifier la configuration de Tomcat elle-même ?).

    Toute piste serait la bienvenue (de même qu'un "c'est purement et simplement impossible" bien argumenté, si c'est effectivement le cas).

    Merci de votre aide.

  2. #2
    Membre habitué

    Profil pro
    Inscrit en
    Décembre 2005
    Messages
    105
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2005
    Messages : 105
    Points : 134
    Points
    134
    Par défaut
    Bonjour

    il doit être possible de configurer struts pour qu'il réagisse sur client1/action.do avec les modules d'application (voir doc struts).

    Si tu y arrive, pour le reste se sera plus compliqué (pour les images et les jsp).

    La solution que j'ai déja mise en oeuvre et qui fonctionne juste pour les styles et les images, est la suivante:
    - lors du premier appel, le partenaire envoie un paramètre
    - ce paramètre est alors stocké en session.
    - si le paramètre est absent, on en fixe un par défaut.
    - on ecrit en suite une série de tag pour les images,et les feuilles de style qui calcule les url en fonction du paramètre en session.

    De cette façon, tous les éléments statiques de type style et images peuvent être stoqués dans une autre webapp (une par partenaire).

    Cette solution n'est valable que si les jsp, et le workflow est identique pour tous les partenaires.

    Si la mise en page doit varier en fonction des partenaires, le pb est plus complexe.

    Cordialement
    Willy78

  3. #3
    Membre à l'essai
    Inscrit en
    Juin 2002
    Messages
    13
    Détails du profil
    Informations forums :
    Inscription : Juin 2002
    Messages : 13
    Points : 12
    Points
    12
    Par défaut
    Youpi j'ai trouvé la solution !
    En fait il fallait faire un filtre (déclaré par la balise filter dans web.xml) et encapsuler la HttpServletRequest dans un HttpServletRequestWrapper de mon cru, qui filtre le répertoire en question.

    Il suffit alors de garder le répertoire client dans une variable, rajouter une méthode getRepertoireClient(), et surcharger getRequestURI, getRequestURL et getContextPath pour renvoyer quelque chose de cohérent aux autres objets utilisant la HttpServletRequest (i.e. enlever le répertoire client de requestURL et requestURI, et le rajouter dans le contextPath).

    Et avec ça, ça marche nickel. :-)

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 1
    Dernier message: 04/12/2009, 19h17
  2. URL Rewriting - répertoire virtuel
    Par Samyhijodelaluna dans le forum Langage
    Réponses: 2
    Dernier message: 09/07/2007, 11h29
  3. récupérer le path d'un répertoire virtuel dans IIS
    Par ep31 dans le forum Visual C++
    Réponses: 4
    Dernier message: 30/01/2007, 12h20
  4. [Struts] Passer une variable dans l'url
    Par pilz dans le forum Struts 1
    Réponses: 2
    Dernier message: 30/03/2005, 15h23
  5. [ Struts ] recuperer une valeur dans une url?
    Par njac dans le forum Struts 1
    Réponses: 2
    Dernier message: 02/06/2004, 14h24

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo