Структура папок веб-приложения Java

Как новичок в J2EE, я недавно начал разрабатывать свой собственный проект с нуля, используя Ядро J2EE: Servlets & Jsps.

Я не мог оценить, правильная структура папок моего проекта или нет. Вот структура папок моего проекта.

Прежде чем задать вопрос, я признаю, что не мог ответить или не оправдать, если кто-то спросит меня, почему такой тип структуры папок. Вопрос: это хороший знак для размещения моих jsps вне web-inf. Если нет, то почему это так? Если да, то почему?

Существует ли какое-либо стандартное соглашение о структуре папок для веб-приложения J2EE, я знаю, что maven поднял некоторые стандарты, но, тем не менее, мы можем настроить его в соответствии с требованиями, которые я считаю.

Я немного погуглил и нашел две ссылки 1 2

где в ответах нет на той же странице, из которой я не мог сделать никакого вывода.

Какие моменты следует учитывать при планировании структуры папок для веб-приложения J2EE, важно, куда должен входить статический контент Jsps и почему?

Стандартная структура файла WAR:

/META-INF
   Standard jar stuff like manifest.xml
/WEB-INF
  web.xml
  /classes
    /com...etc.
  /lib

Maven генерирует это для вас, используя ваш src / main / java, resources, webapp и ваши зависимости (помещая их в / lib) в maven-webapp-plugin , но это реализация. Важно понимать, что все, что вы помещаете в WEB-INF, не доступно извне , тогда как все в корневом каталоге WAR является общедоступным.

Как правило, вы не хотите помещать многое в корень, так как вы хотите, чтобы ваше приложение обрабатывало весь доступ, используя сервлеты и фильтры, которые вы определили в web.xml. Распространено видеть в корневом каталоге index.html (или .jsp), который перенаправляет сервлет, например, действие Struts .

Типичные реализации MVC, такие как Stripes или Struts, не разрешают пользователю получать доступ к JSP напрямую, предпочитая, чтобы JSP были только для просмотра. Они рекомендуют создавать контроллеры, которые пересылают в JSP после обработки запроса, а JSP просто отображают результат. Например, при отправке формы для /loginзапуска будет выполнено действие, которое обрабатывает запрос на вход в систему, создает сеанс пользователя и перенаправляет пользователя в окно входа в систему JSP домашней страницы.

Обычный ответ на вопрос "что такое правильный путь?" или "это правильный путь?" это ..... это зависит .

Все, что я могу сделать, это рассказать вам о плюсах и минусах конкретных идей. То, что следует, на 100% мое мнение. Я не знаю каких-либо конкретных требований или правил. Я уверен, что кто-то не согласится со мной.

JSP-х

Давайте поработаем над тем, помещать ли JSP в WEB-INF или нет.

Плюсы размещения JSP в WEB-INF:

• Вы контролируете, как выполняются JSP. Если вы хотите, чтобы JSP был параметризован и использовался повторно (что на самом деле очень сложно с JSP), вы можете поместить их в WEB-INF и использовать сервлет, контроллер действий Struts или какой-либо другой фронт-контроллер для предварительной обработки. а затем передать управление JSP, передавая в правильном контексте среды (например, атрибуты запроса, любые проверки безопасности, санацию параметров и т. д.)
• Вы можете программно или даже на уровне брандмауэра или IDS блокировать HTTP-запросы к * .jsp, чтобы уменьшить вероятность того, что кто-то загрузит JSP в корневой веб-каталог, а затем сможет выполнять код в качестве веб-сервера. Им придется переписать существующую JSP. Не огромный выигрыш в безопасности, но он делает компромисс немного сложнее.
• Обеспечивает хорошие привычки, такие как MVC, фронт-контроллер, фильтры сервлетов, внедрение зависимостей и т. Д., В отличие от большого чудовищного JSP, который выполняет всю работу сам, и его трудно читать / поддерживать.

Минусы размещения JSP в WEB-INF:

• Вы не можете получить доступ к странице напрямую, даже если это простая отдельная страница, которая не требует предварительной обработки. Это связано с тем, что файлы в / WEB-INF не обслуживаются контейнером сервлета.

Статические файлы

С точки зрения чисто статических файлов, таких как HTML, изображения, таблицы стилей, javascript и т. Д. Поместите их в корневой каталог сети (в вашем случае my_app), но НЕ / WEB-INF (поскольку они недоступны).

Общий макет

Что касается общей структуры каталогов, то это в некоторой степени зависит от процесса сборки. Мне нравится хранить все под "src" или "source", потому что это дает понять, какие файлы генерируются при сборке, а какие являются чистыми исходными файлами. mainпозволяет отделить тестовый код, например классы junit, от основного исходного кода, что тоже хорошо. Но если у вас нет юнит-тестов (о нет!), То это бессмысленное различие.

С другой стороны, если вы вообще не управляете веб-корнем во время сборки (например, если это все JSP и статические файлы), то, возможно, вы сохраните его на верхнем уровне, например, /webrootили /deployскопируете файлы по мере необходимости, такие как .class или .jar файлы. Это привычка людей (особенно разработчиков) к чрезмерной организации. Хорошим признаком чрезмерной организации является наличие множества папок только с одной подпапкой.

Что вы показали

Вы указали, что соблюдаете соглашение, установленное maven, поэтому, если вы уже используете maven, просто придерживайтесь этого макета. В макете, который вы описали, нет ничего плохого.

Ну, ваш src / main / webapp наверняка напоминает мне проект maven. И это хорошо.

Для my_app / jsps я не уверен, хотя. Разработчики обычно оставляют свои jsp в папке webapp, или, если вы хотите сделать небольшое отображение URL, в каталоге webapp / jsp.

!Предупреждение! : Вы никогда не должны помещать файл jsp в web-inf. Ваш WEB-INF должен содержать только XML-файлы для настройки вашего сайта. Помните, что ваш JSP является веб-страницей или частью веб-страницы.

Вы можете использовать имя папки, как шаблон, частичное ... все, что вам подходит. Это должно быть легко найти для незнакомца. Просто разделите различные типы содержимого, такие как полные страницы, шаблоны, частичные представления ...

Я согласен с Брайсом . Я тоже новичок в J2EE, но думаю, что лучше работать легко и четко в начале.

Корневой папкой является WEBAPP, и вы должны заставить свою веб-структуру думать, что большинство страниц будет там находиться. Если нет, то когда страницы обмениваются данными между ними, вероятно, вы не сможете управлять отношениями между файлами без ошибок.

На самом деле WAR-приложение может быть построено без WEB-INF/web.xml. Можно сделать WAR-приложение только с классами Java внутри.

Источник: элементы дескриптора развертывания web.xml

В аннотациях Java EE стандартный дескриптор развертывания web.xml является необязательным. В соответствии со спецификацией сервлета 3.0 по адресу http://jcp.org/en/jsr/detail?id=315 , аннотации могут быть определены для определенных веб-компонентов, таких как сервлеты, фильтры, прослушиватели и обработчики тегов.

Так что в настоящее время возможно построить WAR, чем выглядит как JAR с .warрасширениями :)

Отвечая на ваш вопрос, структура WAR зависит от ваших требований.

http://en.wikipedia.org/wiki/WAR_(Sun_file_format)