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, woran ich interessiert bin, ist WEB-INF- es enthält web.xmlXML-Dateien zum Einrichten von Servlets, Spring Bean-Verkabelungskontexte sowie JSP-Tags und -Ansichten.

Ich versuche zu verstehen, was diese Struktur einschränkt / definiert. Müssten sich JSP-Dateien beispielsweise immer innerhalb befinden WEB-INFoder könnten sie sich woanders befinden? Und gibt es noch etwas, das reingehen könnte WEB-INF? Der WAR - Dateieintrag von Wikipedia erwähnt classesJava-Klassen und libJAR-Dateien - ich bin mir nicht sicher, ob ich genau verstanden habe, wann diese zusätzlich zu den anderen Speicherorten der Quelldateien benötigt werden.

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

Innerhalb der genannten Anwendungshierarchie existiert ein spezielles Verzeichnis WEB-INF. Dieses Verzeichnis enthält alle mit der Anwendung verbundenen Elemente, die sich nicht im Dokumentstamm der Anwendung befinden. Der WEB-INFKnoten ist nicht Teil des öffentlichen Dokumentbaums der Anwendung . Keine im WEB-INFVerzeichnis enthaltene Datei darf vom Container direkt an einen Client geliefert werden. Der Inhalt des WEB-INFVerzeichnisses ist jedoch für Servlet-Code mit den Methodenaufrufen getResource und getResourceAsStreamauf dem sichtbar ServletContextund kann mithilfe der RequestDispatcherAufrufe verfügbar gemacht werden .

Dies bedeutet, dass WEB-INFRessourcen für den Ressourcenlader Ihrer Webanwendung 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 Klassendateien oder Eigenschaftendateien oder andere vertrauliche Informationen in den WEB-INFOrdner. Andernfalls wäre der Zugriff über eine einfache statische URL (nützlich zum Laden von CSS oder Javascript).

Ihre JSP-Dateien können jedoch aus technischer Sicht überall sein. Zum Beispiel können Sie sie im Frühjahr so ​​konfigurieren, dass sie WEB-INFexplizit vorhanden sind:

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

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

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

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

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

Während Sie normalerweise frei sind, Ihren eigenen Erstellungsprozess zu entwerfen, verwenden heutzutage die meisten Leute einen standardisierten Ansatz wie Apache Maven . Unter anderem definiert Maven Standardeinstellungen, für welche Ressourcen in der Projektstruktur welche Ressourcen im resultierenden Artefakt zugeordnet sind (das resultierende Artefakt ist in diesem Fall die WAR-Datei). In einigen Fällen besteht die Zuordnung aus einem einfachen Kopierprozess, in anderen Fällen umfasst der Zuordnungsprozess eine Transformation, z. B. Filtern oder Kompilieren und andere.

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

Ein weiteres Beispiel : Der WEB-INF/libOrdner 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 die erforderlichen JAR-Dateien automatisch in den WEB-INF/libOrdner für Sie. Das erklärt, warum Sie keinen libOrdner in einem Maven-Projekt haben.

Wenn Sie eine Java EE-Webanwendung bereitstellen (mit oder ohne Frameworks), muss ihre Struktur einigen Anforderungen / Spezifikationen entsprechen. Diese Spezifikationen stammen von:

• Der Servlet-Container (zB Tomcat)
• Java Servlet API
• Ihre Anwendungsdomäne

1. Die Anforderungen an den Servlet-Container
   Wenn Sie Apache Tomcat verwenden, muss das Stammverzeichnis Ihrer Anwendung im Ordner webapp abgelegt werden. Dies kann anders sein, wenn Sie einen anderen Servlet-Container oder Anwendungsserver verwenden.
   
   

2. Anforderungen an die
   Java-Servlet-API Die Java-Servlet-API gibt an, dass Ihr Stammanwendungsverzeichnis die folgende Struktur haben 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 die Anforderungen des Servlet-Containers (oder Anwendungsservers) und die Anforderungen der Java-Servlet-API erfüllt haben, können Sie die anderen Teile Ihrer Webanwendung nach Bedarf organisieren.
- Sie können Ihre Ressourcen (JSP-Dateien, Nur-Text-Dateien, Skriptdateien) in Ihrem Anwendungsstammverzeichnis ablegen. Dann können Benutzer jedoch direkt über ihren Browser auf sie zugreifen, anstatt dass ihre Anforderungen von einer von Ihrer Anwendung bereitgestellten Logik verarbeitet werden. Um zu verhindern, dass auf Ihre Ressourcen direkt zugegriffen wird, können Sie sie in das WEB-INF-Verzeichnis stellen, auf dessen Inhalt nur der Server zugreifen kann.
-Wenn Sie einige Frameworks verwenden, verwenden diese häufig Konfigurationsdateien. Bei den meisten dieser Frameworks (Struts, Spring, Hibernate) müssen Sie ihre Konfigurationsdateien im Klassenpfad (dem Verzeichnis "classes") ablegen.

Sie sollten in WEB-INF alle Seiten oder Seitenstücke einfügen, die Sie nicht öffentlich machen möchten. Normalerweise befinden sich JSP oder Facelets außerhalb von WEB-INF. In diesem Fall sind sie jedoch für jeden Benutzer leicht zugänglich. Falls Sie einige Berechtigungsbeschrä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 auf Ihrem Server ausgeführten Anwendungen verfügbar sein), sondern nur für diese bestimmte Anwendung.

Im Allgemeinen gehen viele Konfigurationsdateien auch in WEB-INF.

WEB-INF / classes ist in jeder Web-App vorhanden, da in diesem Ordner alle kompilierten Quellen abgelegt sind (nicht JARS, sondern kompilierte Java-Dateien, die Sie selbst geschrieben haben).

Diese Konvention wird aus Sicherheitsgründen befolgt. Wenn beispielsweise nicht autorisierte Personen direkt über die URL auf die Root-JSP-Datei zugreifen dürfen, können sie ohne Authentifizierung durch die gesamte Anwendung navigieren und auf alle gesicherten Daten zugreifen.

Es gibt eine Konvention (nicht erforderlich), JSP-Seiten im WEB-INF-Verzeichnis abzulegen, damit sie nicht tief verknüpft oder mit Lesezeichen versehen werden können. Auf diese Weise müssen alle Anfragen an die JSP-Seite über unsere Anwendung geleitet werden, damit die Benutzererfahrung garantiert ist.