Для чого використовується WEB-INF у веб-додатку Java EE?

Я працюю над веб-додатком 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 для налаштування сервлетів, контексти проводки весняних бобів та теги та представлення JSP.

Я намагаюся зрозуміти, що обмежує / визначає цю структуру. Наприклад, чи завжди файли JSP повинні знаходитись у них, WEB-INFчи вони можуть бути десь ще? А чи є ще щось, що може зайти WEB-INF? Вхідні файли Вікіпедії згадують classesдля класів Java та libфайлів JAR - не впевнений, що я повністю зрозумів, коли вони знадобляться на додаток до інших файлів вихідних файлів.

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

В ієрархії додатків існує спеціальний каталог WEB-INF. У цьому каталозі містяться всі речі, пов’язані з програмою, які відсутні в корені документа програми. Вузол не є частиною дерева документа публічної заяви . Жоден файл, що міститься в каталозі, не може безпосередньо контейнеру подавати клієнту. Однак вміст каталогу видно коду сервлетів за допомогою і викликів методу на , і може бути відкрито за допомогою викликів.WEB-INFWEB-INFWEB-INFgetResourcegetResourceAsStreamServletContextRequestDispatcher

Це означає, що 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 файли статті наведені приклади папок , необхідних в специфікації Servlet під час виконання.

Важливо зробити різницю між структурою проекту та структурою отриманого файлу 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.

Коли ви розгортаєте веб-додаток Java EE (використовуючи рамки чи ні), його структура повинна відповідати деяким вимогам / технічним умовам. Ці специфікації походять від:

• Контейнер для сервлетів (наприклад, Tomcat)
• API Java Servlet
• Ваш домен програми

1. Вимоги до контейнера сервлетів
   Якщо ви використовуєте Apache Tomcat, кореневий каталог вашої програми повинен бути розміщений у папці webapp. Це може бути інакше, якщо ви використовуєте інший контейнер сервлетів або сервер додатків.
   
   

2. Вимоги API
   Java Servlet API API сервлетів Java повідомляє, що ваш каталог кореневих програм повинен мати таку структуру:

   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.

3. Ваш домен додатка
Тепер, коли ви дотримувались вимог контейнера Servlet (або сервера додатків) та вимог API Java Servlet, ви можете організувати інші частини вашого веб-сервісу залежно від того, що вам потрібно.
- Ви можете розмістити свої ресурси (файли JSP, звичайні текстові файли, файли сценаріїв) у кореневому каталозі програми. Але тоді люди можуть отримати доступ до них безпосередньо зі свого браузера, замість того, щоб їхні запити оброблялися за певною логікою, наданою вашою заявкою. Отже, щоб запобігти прямому доступу до ваших ресурсів, ви можете помістити їх у каталог WEB-INF, вміст якого доступний лише сервером.
-Якщо ви використовуєте деякі рамки, вони часто використовують файли конфігурації. Більшість з цих фреймворків (struts, spring, hibernate) вимагають, щоб ви розмістили їх конфігураційні файли у classpath (каталог "класів").

Ви повинні розміщувати в WEB-INF будь-які сторінки або фрагменти сторінок, які ви не хочете бути загальнодоступними. Зазвичай JSP або фасети зустрічаються за межами WEB-INF, але в цьому випадку вони легко доступні для будь-якого користувача. Якщо у вас є деякі обмеження на авторизацію, WEB-INF може бути використаний для цього.

WEB-INF / lib може містити сторонні бібліотеки, які ви не хочете упаковувати на системному рівні (JAR можуть бути доступні для всіх програм, що працюють на вашому сервері), але тільки для цієї конкретної програми.

Взагалі кажучи, багато файлів конфігурацій також переходять у WEB-INF.

Що стосується WEB-INF / класів - він існує в будь-якому веб-додатку, тому що це папка, де розміщуються всі складені джерела (не JARS, а компільовані файли .java, які ви написали самі).

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

Існує умова (не обов'язково) розміщувати сторінки jsp під каталогом WEB-INF, щоб вони не могли бути глибоко пов’язані або закладені у закладки. Таким чином, всі запити на сторінку jsp повинні бути спрямовані через наш додаток, щоб гарантувати користувачеві досвід.