A quoi sert WEB-INF dans une application Web Java EE?

Question

Je travaille sur une application Web Java EE avec la structure de code source suivante:

src/main/Java                 <-- multiple packages containing Java classes
src/test/Java                 <-- multiple packages containing JUnit tests
src/main/resources            <-- includes properties files for textual messages
src/main/webapp/resources     <-- includes CSS, images and all Javascript files
src/main/webapp/WEB-INF
src/main/webapp/WEB-INF/tags
src/main/webapp/WEB-INF/views

Le bit qui m'intéresse est WEB-INF - il contient web.xml, des fichiers XML pour la configuration de servlets, des contextes de câblage Spring Bean, des balises et des vues JSP.

J'essaie de comprendre ce qui limite/définit cette structure. Par exemple. Les fichiers JSP doivent-ils toujours se trouver dans WEB-INF ou pourraient-ils se trouver ailleurs? Et y a-t-il autre chose qui pourrait aller dans WEB-INF? L'entrée fichiers WAR de Wikipedia mentionne classes pour Java classes et lib pour les fichiers JAR - je ne suis pas sûr d'avoir bien compris à quel moment ils seraient nécessaires en plus aux autres emplacements de fichier source.

Answer 1

Le spécification Servlet 2.4 dit ceci à propos de WEB-INF (page 70):

Un répertoire spécial existe dans la hiérarchie d'applications nommé WEB-INF. Ce répertoire contient tous les éléments liés à l’application qui ne se trouvent pas dans la racine du document de l’application. Le noeud WEB-INF ne fait pas partie de l'arborescence de documents publics de l'application . Aucun fichier contenu dans le répertoire WEB-INF ne peut être servi directement à un client par le conteneur. Toutefois, le contenu du répertoire WEB-INF est visible pour le code de servlet à l'aide des appels de méthodes getResource et getResourceAsStream sur le ServletContext et peut être exposé à l'aide des appels RequestDispatcher.

Cela signifie que les ressources WEB-INF sont accessibles au chargeur de ressources de votre application Web et ne sont pas directement visibles pour le public.

C’est la raison pour laquelle de nombreux projets mettent leurs ressources comme des fichiers JSP, des JAR/bibliothèques et leurs propres fichiers de classe ou fichiers de propriété ou toute autre information confidentielle dans le dossier WEB-INF. Sinon, ils seraient accessibles en utilisant une simple URL statique (utile pour charger CSS ou Javascript par exemple).

Vos fichiers JSP peuvent être n'importe où d'un point de vue technique. Par exemple, au printemps, vous pouvez les configurer de manière à être dans WEB-INF explicitement:

<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver"
    p:prefix="/WEB-INF/jsp/" 
    p:suffix=".jsp" >
</bean>

Les dossiers WEB-INF/classes et WEB-INF/lib mentionnés dans l'article fichiers WAR de Wikipedia sont des exemples de dossiers requis par la spécification Servlet au moment de l'exécution.

Il est important de faire la différence entre la structure d'un projet et la structure du fichier WAR obtenu.

Dans certains cas, la structure du projet reflète partiellement la structure du fichier WAR (pour les ressources statiques telles que les fichiers JSP ou les fichiers HTML et JavaScript, mais ce n'est pas toujours le cas.

La transition de la structure du projet au fichier WAR résultant est effectuée par un processus de construction.

Alors que vous êtes généralement libre de concevoir votre propre processus de construction, de nos jours, la plupart des gens utilisent une approche normalisée telle que Apache Maven . Entre autres choses, Maven définit les valeurs par défaut pour lesquelles les ressources de la structure de projet correspondent aux ressources de l'artefact résultant (l'artefact résultant est le fichier WAR, dans ce cas). Dans certains cas, le mappage consiste en un processus de copie standard. Dans d'autres cas, le processus de mappage comprend une transformation, telle que le filtrage ou la compilation, etc.

Un exemple : le dossier WEB-INF/classes contiendra plus tard toutes les classes et ressources Java compilées (src/main/Java et src/main/resources) qui doit être chargé par le chargeur de classe pour démarrer l’application.

Autre exemple : Le dossier WEB-INF/lib contiendra ultérieurement tous les fichiers jar nécessaires à l'application. Dans un projet maven, les dépendances sont gérées pour vous et maven copie automatiquement les fichiers jar nécessaires dans le dossier WEB-INF/lib. Cela explique pourquoi vous n'avez pas de dossier lib dans un projet maven.

Answer 2

Lorsque vous déployez une application Web EE Java (utilisant des infrastructures ou non), sa structure doit respecter certaines exigences/spécifications. Ces spécifications proviennent de:

• Le conteneur de servlet (par exemple Tomcat)
• API Java Servlet
• Votre domaine d'application

1. Les exigences du conteneur Servlet
   Si vous utilisez Apache Tomcat, le répertoire racine de votre application doit être placé dans le dossier webapp. Cela peut être différent si vous utilisez un autre conteneur de servlet ou serveur d'applications.
   
   

2. Configuration requise pour l'API Java Servlet
   L'API Java Servlet indique que votre répertoire d'application racine doit avoir la structure suivante:

   ApplicationName
   |
   |--META-INF
   |--WEB-INF
         |_web.xml       <-- Here is the configuration file of your web app(where you define servlets, filters, listeners...)
         |_classes       <--Here goes all the classes of your webapp, following the package structure you defined. Only 
         |_lib           <--Here goes all the libraries (jars) your application need
   

Ces exigences sont définies par l'API de servlet Java.

3. Votre domaine d'application
Maintenant que vous avez respecté les exigences du conteneur Servlet (ou du serveur d'applications) et les exigences de l'API Java, vous pouvez organiser les autres parties de votre application Web en fonction de vos besoins.
- Vous pouvez placer vos ressources (fichiers JSP, fichiers de texte brut, fichiers de script) dans le répertoire racine de votre application. Cependant, les utilisateurs peuvent y accéder directement à partir de leur navigateur, au lieu que leurs demandes soient traitées par une logique fournie par votre application. Ainsi, pour éviter que vos ressources ne soient directement utilisées de cette manière, vous pouvez les placer dans le répertoire WEB-INF, dont le contenu est uniquement accessible par le serveur.
- Si vous utilisez des frameworks, ils utilisent souvent des fichiers de configuration. La plupart de ces frameworks (struts, spring, hibernate) nécessitent de placer leurs fichiers de configuration dans le classpath (le répertoire "classes").

Answer 3

Vous devez mettre dans WEB-INF les pages, ou morceaux de pages, que vous ne souhaitez pas voir public. En général, les fichiers JSP ou facelets se trouvent en dehors de WEB-INF, mais dans ce cas, ils sont facilement accessibles à tout utilisateur. Si vous avez des restrictions d’autorisation, WEB-INF peut être utilisé pour cela.

WEB-INF/lib peut contenir des bibliothèques tierces que vous ne souhaitez pas compresser au niveau du système (les fichiers JAR peuvent être disponibles pour toutes les applications exécutées sur votre serveur), mais uniquement pour cette application particulière.

De manière générale, de nombreux fichiers de configuration vont également dans WEB-INF.

En ce qui concerne WEB-INF/classes, il existe dans toutes les applications Web, car c’est le dossier dans lequel sont placées toutes les sources compilées (pas les fichiers JARS, mais les fichiers .Java compilés que vous avez écrits vous-même).

Answer 4

Cette convention est suivie pour des raisons de sécurité. Par exemple, si une personne non autorisée est autorisée à accéder au fichier JSP racine directement à partir d'une URL, elle peut naviguer dans toute l'application sans aucune authentification et accéder à toutes les données sécurisées.

Answer 5

Il existe une convention (non nécessaire) selon laquelle les pages jsp doivent être placées dans le répertoire WEB-INF, de sorte qu'elles ne puissent pas être liées en profondeur ni à des signets. De cette façon, toutes les demandes adressées à la page jsp doivent être acheminées via notre application, de sorte que l'expérience utilisateur soit garantie.