Что такое WEB-INF, используемый в веб-приложении Java EE?

Ответ 1

спецификация Servlet 2.4 говорит о WEB-INF (стр. 70):

В иерархии приложений с именем WEB-INF. Этот каталог содержит все, что связано с приложение arent в корневом каталоге приложения. The WEB-INF node не является частью общедоступного дерева документов приложение. Нет файлов, содержащихся в каталоге 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, упомянутые в Wikipedia WAR файлы, являются примерами папок, требуемых спецификацией Servlet во время выполнения.

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

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

Переход от структуры проекта в полученный WAR файл выполняется процессом сборки.

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

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

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

Ответ 2

При развертывании веб-приложения Java EE (с использованием фреймворков или нет) его структура должна соответствовать некоторым требованиям/спецификациям. Эти спецификации взяты из:

• Контейнер сервлета (например, Tomcat)
• API-интерфейс Java Servlet
• Область применения

• Требования к контейнеру Servlet
  Если вы используете Apache Tomcat, корневой каталог приложения должен быть помещен в папку webapp. Это может быть другим, если вы используете другой контейнер сервлетов или сервер приложений.
  
  

• Требования API Java сервлета API Java Servlet утверждает, что каталог корневого приложения должен иметь следующую структуру:

  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
  

Эти требования определяются API-интерфейсом Java Servlet.  3. Ваш домен приложения
Теперь, когда вы выполнили требования к контейнеру Servlet (или серверу приложений) и требованиям API Java Servlet, вы можете организовать другие части вашего webapp на основе того, что вам нужно.
- Вы можете поместить свои ресурсы (файлы JSP, текстовые файлы, script) в корневой каталог приложения. Но тогда люди могут обращаться к ним напрямую из своего браузера, вместо того, чтобы их запросы обрабатывались по некоторой логике, предоставленной вашим приложением. Таким образом, чтобы ваши ресурсы не были доступны напрямую, вы можете поместить их в каталог WEB-INF, содержимое которого доступно только для сервера.
-Если вы используете некоторые фреймворки, они часто используют файлы конфигурации. Большинство этих фреймворков (struts, spring, hibernate) требуют, чтобы вы поместили свои файлы конфигурации в путь к классам (каталог "classes" ).

Ответ 3

Вы должны поместить в WEB-INF любые страницы или части страниц, которые вы не хотите публиковать. Как правило, JSP или facelets находятся вне WEB-INF, но в этом случае они легко доступны для любого пользователя. Если у вас есть некоторые ограничения авторизации, для этого может использоваться WEB-INF.

WEB-INF/lib может содержать сторонние библиотеки, которые вы не хотите упаковывать на системный уровень (JAR могут быть доступны для всех приложений, запущенных на вашем сервере), но только для этого конкретного приложения.

Вообще говоря, многие файлы конфигураций также входят в WEB-INF.

Что касается WEB-INF/classes - он существует в любом веб-приложении, потому что это папка, в которой размещены все скомпилированные источники (а не JARS, но скомпилированные .java файлы, которые вы написали сами).

Ответ 4

Это соглашение соблюдается по соображениям безопасности. Например, если неавторизованному лицу разрешен доступ к корневому JSP файлу непосредственно из URL-адреса, он может перемещаться по всему приложению без какой-либо проверки подлинности и получать доступ ко всем защищенным данным.

Ответ 5

Существует соглашение (не обязательно) размещения jsp-страниц в каталоге WEB-INF, чтобы они не могли быть глубоко связаны или помечены закладкой. Таким образом, все запросы на страницу jsp должны направляться через наше приложение, чтобы гарантировать, что пользовательский интерфейс гарантирован.