Supprimer les images, les CSS et les JS du servlet-mapping

Question

Je suis en train d'utiliser le servlet-mapping suivant dans mon fichier web.xml :

    PostController
    com.webcodei.controller.PostController

    PostController
    /*

Pour effectuer une sorte de recherche. ex:

 http://www.myweb.com/The chaîne de recherche ici 

Mais le problème est que les CSS, JS et images sont traités comme une requête de recherche.

Y a-t-il des modèles qui excluent *.css, *.js, *.gif et autres, afin que les requêtes ne passent pas par mon contrôleur?

Merci beaucoup, au revoir!

Answer 1

Deux options viennent à l'esprit :

1) Généralement, dans une application web comme celle-ci, les URL "action" qui sont gérées par un servlet, sont données soit un sous-répertoire comme "/actions/*" soit une extension comme "*.action" ou "*.do" (c'est ce que fait Struts). De cette façon, il est clair quelles URLs sont destinées au servlet. Il s'agit davantage d'une solution inclusive que de l'exclusive que vous recherchez, mais je ne pense pas que ce que vous voulez soit possible.

2) L'option un peu plus aventureuse est de configurer votre serveur d'application web derrière une installation Apache qui sert les images, css, etc. en tant que fichiers plats, ne transmettant que tout le reste au serveur d'application. Généralement, cela est fait pour alléger la charge de votre serveur d'application. Cela vous demanderait de copier tous ces fichiers dans un répertoire séparé pour qu'Apache les gère.

Answer 2

Au lieu de mettre en liste noire certaines extensions, vous pourriez envisager de mettre en liste blanche les modèles d'URL qui atteignent votre servlet PostController. Par exemple :

    PostController
    com.webcodei.controller.PostController

    PostController
    /*.jsp

si vous utilisez des JSP simples. Maintenant, les requêtes HTTP GET pour les fichiers avec l'extension *.css, *.gif, etc. ne seront pas acheminées via cette servlet.

Comme l'a souligné la personne posant la question, il y a beaucoup plus d'URL qui ne devraient pas être acheminées via ce contrôleur que le contraire.

Answer 3

Jetty interprète web.xml comme vous vous y attendez. J'ai exposé ce problème récemment lorsque j'ai déplacé une application de jetty à tomcat, et tout à coup je ne pouvais plus voir mes ressources statiques. Très frustrant.