Enveloppez la servlet par défaut mais remplacez le chemin Webapp par défaut

Question

J'ai un dossier de contenu HTML statique, imgs, Flash qui vit en dehors du dossier webapp. En ce moment j'utilise un lien symbolique pour mapper ce dossier dans mon répertoire webapp. Le problème que j'ai est quand je annuler le déploiement de mon application, il suit le lien symbolique et supprime tous ces fichiers.

L'une des solutions que j'essaie de mettre en œuvre est une servlet spéciale qui enveloppe le servlet par défaut mais utilise un chemin relatif différent. Je n'arrive pas à trouver comment placer la servlet par défaut d'une manière qui remplace le chemin de servlet par défaut.

Voici ce que je travaille avec:

public void doGet(final HttpServletRequest req, final HttpServletResponse resp) 
    throws ServletException, IOException { 
    final RequestDispatcher rd = getServletContext().getNamedDispatcher("default"); 
    final HttpServletRequest wrapped = new HttpServletRequestWrapper(req) { 

     @Override 
     public String getServletPath() { 
      return "/usr/depot/repository"; 
     } 
    }; 

    rd.forward(wrapped, resp); 
} 

Answer 1

Vous pouvez soit écrire votre propre servlet pour servir du contenu statique (ce qui n'est pas si difficile) ou essayer de étendre plutôt que d'envelopper le DefaultServlet. Dans les deux cas, votre servlet sera configuré à la place de la valeur par défaut dans votre web.xml (en utilisant "default" comme nom de servlet). Ceci dit, DefaultServlet ne servira que du contenu statique sous votre contexte webapp; afin de changer cela, vous devrez créer/lier à JNDI votre propre instance de ProxyDirContext pointant vers le dossier extérieur et je ne suis pas sûr que cela fonctionnera; son processus de configuration est plutôt impliqué.

Essayer de remplacer le chemin de servlet ne vous mènera nulle part.

Answer 2

Ce n'est pas une bonne idée.

Les conteneurs Web ou les serveurs d'applications peuvent être déployés derrière des serveurs Web ou vous pouvez simplement utiliser un serveur Web avec votre conteneur. Il suffit de mettre vos fichiers statiques sous cela et se référer à eux par chemin absolu.

Il n'y a vraiment pas besoin de ce genre de hack (désolé mais c'est ce que c'est).

Soit cela ou simplement les déployer avec l'application Web.

Answer 3

Nous avons un problème similaire que nous avons besoin de partager certains fichiers générés par CMS parmi plusieurs applications. Symlink est le moyen le plus simple de le faire si vous n'utilisez pas Windows.

Nous avons configuré 2 comptes pour CMS et Tomcat. Les fichiers sont en lecture seule sur Tomcat et ne peuvent donc pas être supprimés.

Vous pouvez également écrire une petite extension Tomcat pour pouvoir rechercher des fichiers à plusieurs endroits. Voir ce site web,

http://blog.bazoud.com/post/2009/05/12/Multiples-docbases-avec-tomcat

Votre approche actuelle ne fonctionne pas. Tomcat doit charger toutes les ressources d'un cache en déploiement pour qu'il soit disponible. Il est trop tard pour changer cela dans le traitement des demandes. Cette extension permet à Tomcat de charger des ressources à partir de plusieurs répertoires. L'inconvénient de cette approche est que vous devez mettre un petit JAR dans server/lib.

Answer 4

Vous pouvez remplacer DefaultServlet par votre propre implémentation. Vous pouvez parfaitement le sous-classer, c'est une classe publique. Here sont les spécifications fonctionnelles de DefaultServlet, vous devez y adhérer. D'autre part, vous pouvez ignorer DefaultServlet et optez pour votre propre solution. Vous trouverez un exemple dans here.

Answer 5

J'ai ouvert une source personnalisée qui sert des fichiers provenant d'un chemin de base arbitraire. En outre, il prend en charge la navigation dans les archives compressées imbriquées.

Il est disponible ici: https://bitbucket.org/teslamotors/zip-listing/overview

Answer 6

Vous pouvez passer à un autre chemin au sein de votre contexte webapp. Voici un exemple qui fait différentiel qui sert selon que prend en charge ES6 User-Agent du client:

protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { 
    RequestDispatcher rd = getServletContext().getNamedDispatcher("default"); 
    HttpServletRequest wrapped = new HttpServletRequestWrapper(req) { 
     @Override 
     public String getServletPath() { 
      String prefix = supportsES6(req) ? "/es6" : "/es5"; 
      String newPath = prefix + req.getServletPath(); 
      if (newPath.endsWith("/")) newPath += "index.html"; 
      return newPath; 
     } 
    }; 
    rd.forward(wrapped, resp); 
} 

Cependant, « ES5 » et « ES6 », même si nous utilisons la barre oblique initiale, sont sous-répertoires du contexte ordinaire du webapp . Il n'est pas possible de sortir du répertoire contextuel en utilisant cette méthode.