What is WEB-INF used for in a Java EE web application?

Я работаю над веб-приложением Java EE со следующей структурой каталогов исходного кода:

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

Меня интересует папкаWEB-INF: она содержит web.xml XML-файлы для настройки сервлетов, контексты подключения Spring bean, теги и представления JSP. Я пытаюсь понять, что ограничивает / определяет эту структуру. Например. всегда ли файлы JSP должны находиться внутри WEB-INF или они могут быть где-то еще? И есть ли что - нибудь еще , что могло бы войти WEB-INF? В записи WAR files в Википедии упоминается classes для классов Java и lib для файлов JAR - не уверен, что я полностью понял, когда они понадобятся в дополнение к другим расположениям исходных файлов.

В спецификации Servlet 2.4 сказано это о WEB-INF (стр. 70):

В иерархии приложений существует специальный каталог с именем WEB-INF. Этот каталог содержит все, что связано с приложением и чего нет в корневом каталоге документа приложения. WEB-INF Узел не является частью общедоступного дерева документов приложения. Ни один файл, содержащийся в WEB-INF каталоге, не может быть передан контейнером клиенту напрямую. Однако содержимое WEB-INF каталога видно коду сервлета с помощью getResource и getResourceAsStream вызовов методов в ServletContext, и может быть открыто с помощью RequestDispatcher вызовов.

Это означает, что WEB-INF ресурсы доступны загрузчику ресурсов вашего веб-приложения и не видны напрямую для широкой публики.

Вот почему многие проекты помещают свои ресурсы, такие как файлы JSP, JAR / библиотеки и свои собственные файлы классов или файлы свойств, или любую другую конфиденциальную информацию в WEB-INF папку. В противном случае они были бы доступны с помощью простого статического URL (полезного, например, для загрузки CSS или Javascript).

Ваши JSP-файлы могут находиться где угодно, хотя с технической точки зрения. Например, в Spring вы можете настроить их так, чтобы они были в WEB-INF явно:

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

Папки WEB-INF/classes и WEB-INF/lib, упомянутые в статье WAR files в Википедии, являются примерами папок, требуемых спецификацией сервлета во время выполнения.

Важно проводить различие между структурой проекта и структурой результирующего файла WAR.

Структура проекта в некоторых случаях будет частично отражать структуру файла WAR (для статических ресурсов, таких как файлы JSP или HTML и JavaScript, но это не всегда так.

Переход из структуры проекта в результирующий файл WAR осуществляется в процессе сборки.

Хотя обычно вы вольны разрабатывать свой собственный процесс сборки, в настоящее время большинство людей будут использовать стандартизированный подход, такой как Apache Maven. Среди прочего, Maven определяет значения по умолчанию, для которых ресурсы в структуре проекта сопоставляются с ресурсами в результирующем артефакте (в данном случае результирующим артефактом является файл WAR). В некоторых случаях сопоставление состоит из простого процесса копирования, в других случаях процесс сопоставления включает преобразование, такое как фильтрация или компиляция, и другие.

Один пример: WEB-INF/classes Папка позже будет содержать все скомпилированные классы и ресурсы Java (src/main/java и src/main/resources), которые должны быть загружены загрузчиком классов для запуска приложения.

Другой пример: WEB-INF/lib папка позже будет содержать все файлы jar, необходимые приложению. В проекте maven зависимости управляются за вас, и maven автоматически копирует необходимые файлы jar в WEB-INF/lib папку для вас. Это объясняет, почему у вас нет lib папки в проекте maven.

When you deploy a Java EE web application (using frameworks or not),its structure must follow some requirements/specifications. These specifications come from :

• The servlet container (e.g Tomcat)
• Java Servlet API
  
• Your application domain

1. The Servlet container requirements
   
   If you use Apache Tomcat, the root directory of your application must be placed in the webapp folder. That may be different if you use another servlet container or application server.
   
   



2. Java Servlet API requirements
   
   Java Servlet API states that your root application directory must have the following structure :

   
   

   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
   

These requirements are defined by Java Servlet API.


3. Your application domain

Now that you've followed the requirements of the Servlet container(or application server) and the Java Servlet API requirements, you can organize the other parts of your webapp based upon what you need.
- You can put your resources (JSP files, plain text files, script files) in your application root directory. But then, people can access them directly from their browser, instead of their requests being processed by some logic provided by your application. So, to prevent your resources being directly accessed like that, you can put them in the WEB-INF directory, whose contents is only accessible by the server.
-If you use some frameworks, they often use configuration files. Most of these frameworks (struts, spring, hibernate) require you to put their configuration files in the classpath (the "classes" directory).

You should put in WEB-INF any pages, or pieces of pages, that you do not want to be public. Usually, JSP or facelets are found outside WEB-INF, but in this case they are easily accesssible for any user. In case you have some authorization restrictions, WEB-INF can be used for that.

WEB-INF/lib can contain 3rd party libraries which you do not want to pack at system level (JARs can be available for all the applications running on your server), but only for this particular applciation.

Generally speaking, many configurations files also go into WEB-INF.

As for WEB-INF/classes - it exists in any web-app, because that is the folder where all the compiled sources are placed (not JARS, but compiled .java files that you wrote yourself).

This convention is followed for security reasons. For example if unauthorized person is allowed to access root JSP file directly from URL then they can navigate through whole application without any authentication and they can access all the secured data.