Wofür wird WEB-INF in einer Java EE-Webanwendung verwendet?

Ich arbeite an einer Java EE-Webanwendung mit der folgenden Quellcodestruktur:

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 

Das Bit, das mich interessiert, ist WEB-INF – es enthält web.xml , XML-Dateien zum Einrichten von Servlets, Spring-Bean-Verdrahtungskontexten und JSP-Tags und -Ansichten.

Der Fragetitel ist grundlegend, aber was ich versuche zu verstehen, ist, was diese Struktur einschränkt / definiert. ZB müssten JSP-Dateien immer innerhalb von WEB-INF oder könnten sie woanders sein? Und gibt es noch etwas, das in WEB-INF gehen könnte? Der Wikipedia-Eintrag für WAR-Dateien erwähnt classes für Java-classn und lib für JAR-Dateien – ich bin mir nicht sicher, ob ich genau verstanden habe, wann diese zusätzlich zu den anderen Quelldateien benötigt werden.

Solutions Collecting From Web of "Wofür wird WEB-INF in einer Java EE-Webanwendung verwendet?"

Die Servlet 2.4-Spezifikation sagt das über WEB-INF (Seite 70):

Ein spezielles Verzeichnis existiert innerhalb der Anwendungshierarchie namens WEB-INF . Dieses Verzeichnis enthält alle zu der Anwendung gehörigen Dinge, die sich nicht im Dokumentenstamm der Anwendung befinden. Der WEB-INF Knoten ist nicht Teil des öffentlichen Dokumentbaums der Anwendung . Keine Datei, die im Verzeichnis WEB-INF kann vom Container direkt an einen Client gesendet werden. Der Inhalt des WEB-INF Verzeichnisses ist jedoch für Servlet-Code mit den getResource und getResourceAsStream im ServletContext und kann mit den RequestDispatcher Aufrufen RequestDispatcher werden.

Dies bedeutet, dass WEB-INF Ressourcen für den Ressourcenlader Ihrer Web-Anwendung zugänglich und für die Öffentlichkeit nicht direkt sichtbar sind.

Aus diesem Grund legen viele Projekte ihre Ressourcen wie JSP-Dateien, JARs / Bibliotheken und ihre eigenen classndateien oder Eigenschaftsdateien oder andere vertrauliche Informationen in den Ordner WEB-INF . Andernfalls wären sie mit einer einfachen statischen URL zugänglich (zB um CSS oder Javascript zu laden).

Ihre JSP-Dateien können sich aus technischer Sicht überall befinden. Zum Beispiel können Sie sie im Spring so ​​konfigurieren, dass sie explizit in WEB-INF :

   

Die im Wikipedia-Artikel WAR-Dateien erwähnten Ordner WEB-INF/classes und WEB-INF/lib sind Beispiele für Ordner, die zur Laufzeit von der Servlet-Spezifikation benötigt werden.

Es ist wichtig, zwischen der Struktur eines Projekts und der Struktur der resultierenden WAR-Datei zu unterscheiden.

Die Struktur des Projekts spiegelt teilweise die Struktur der WAR-Datei (für statische Ressourcen wie JSP-Dateien oder HTML- und JavaScript-Dateien) wider, dies ist jedoch nicht immer der Fall.

Der Übergang von der Projektstruktur in die resultierende WAR-Datei erfolgt durch einen Build-process.

Während Sie in der Regel frei sind, Ihren eigenen Build-process zu entcasting, werden heutzutage die meisten Leute einen standardisierten Ansatz wie Apache Maven verwenden . Maven definiert unter anderem Standardwerte, für die Ressourcen in der Projektstruktur den Ressourcen im resultierenden Artefakt zugeordnet werden (das resultierende Artefakt ist in diesem Fall die WAR-Datei). In einigen Fällen besteht das Mapping aus einem einfachen Kopierprozess. In anderen Fällen umfasst der Mapping-process eine Transformation, z. B. Filtern oder Kompilieren und andere.

Ein Beispiel : Der Ordner WEB-INF/classes enthält später alle kompilierten Java-classn und Ressourcen ( src/main/java und src/main/resources ), die vom Classloader geladen werden müssen, um die Anwendung zu starten.

Ein anderes Beispiel : Der Ordner WEB-INF/lib enthält später alle JAR-Dateien, die von der Anwendung benötigt werden. In einem Maven-Projekt werden die Abhängigkeiten für Sie verwaltet und maven kopiert automatisch die benötigten JAR-Dateien für Sie in den Ordner WEB-INF/lib . Das erklärt, warum Sie in einem Maven-Projekt keinen lib Ordner haben.

Wenn Sie eine Java EE-Webanwendung bereitstellen (unter Verwendung von Frameworks oder nicht), muss ihre Struktur bestimmten Anforderungen / Spezifikationen entsprechen. Diese Spezifikationen stammen aus:

  • Der Servlet-Container (zB Tomcat)
  • Java-Servlet-API
  • Ihre Anwendungsdomäne
  1. Die Anforderungen des Servlet-Containers
    Wenn Sie Apache Tomcat verwenden, muss das Stammverzeichnis Ihrer Anwendung in den Ordner “webapp” gestellt werden. Das kann anders sein, wenn Sie einen anderen Servlet-Container oder Anwendungsserver verwenden.
  2. Java-Servlet-API-Anforderungen
    Die Java-Servlet-API gibt an, dass das Stammanwendungsverzeichnis die folgende Struktur aufweisen muss:

     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 

Diese Anforderungen werden von der Java-Servlet-API definiert.

3. Ihre Anwendungsdomäne
Nachdem Sie nun die Anforderungen des Servlet-Containers (oder Anwendungsservers) und der Java-Servlet-API-Anforderungen erfüllt haben, können Sie die anderen Teile Ihrer Webanwendung entsprechend Ihren Anforderungen organisieren.
- Sie können Ihre Ressourcen (JSP-Dateien, einfache Textdateien, Skriptdateien) in Ihrem Anwendungsstammverzeichnis ablegen. Aber dann können die Leute direkt über ihren Browser auf sie zugreifen, anstatt dass ihre Anfragen von einer Logik verarbeitet werden, die von Ihrer Anwendung bereitgestellt wird. Um zu verhindern, dass Ihre Ressourcen direkt darauf zugreifen, können Sie sie in das Verzeichnis WEB-INF stellen, auf dessen Inhalt nur der Server zugreifen kann.
-Wenn Sie einige Frameworks verwenden, verwenden sie oft Konfigurationsdateien. Bei den meisten dieser Frameworks (Struts, Spring, Hibernate) müssen Sie ihre Konfigurationsdateien in den classnpfad (das Verzeichnis "classes") stellen.

Sie sollten in WEB-INF alle Seiten oder Seiten einfügen, die nicht öffentlich sein sollen. Normalerweise werden JSPs oder Facelets außerhalb von WEB-INF gefunden, aber in diesem Fall sind sie für jeden Benutzer leicht zugänglich. Falls Sie Autorisierungseinschränkungen haben, kann WEB-INF dafür verwendet werden.

WEB-INF / lib kann Bibliotheken von Drittanbietern enthalten, die Sie nicht auf Systemebene packen möchten (JARs können für alle Anwendungen auf Ihrem Server verfügbar sein), aber nur für diese bestimmte Anwendung.

Im Allgemeinen gehen viele Konfigurationsdateien auch in WEB-INF.

Wie für WEB-INF / classn – es existiert in jeder Web-App, denn das ist der Ordner, in dem alle kompilierten Quellen platziert sind (nicht JARS, sondern kompilierte .java-Dateien, die Sie selbst geschrieben haben).

Diese Konvention wird aus Sicherheitsgründen befolgt. Wenn beispielsweise eine nicht autorisierte Person direkt von der URL auf die root-JSP-Datei zugreifen kann, kann sie ohne Authentifizierung durch die gesamte Anwendung navigieren und auf alle gesicherten Daten zugreifen.

Es gibt eine Konvention (nicht notwendig), JSP-Seiten unter das Verzeichnis WEB-INF zu stellen, damit sie nicht tief verlinkt oder mit Lesezeichen versehen werden können. Auf diese Weise müssen alle Anfragen an die jsp-Seite durch unsere Anwendung geleitet werden, damit die Benutzererfahrung gewährleistet ist.