Пользовательский загрузчик классов, выполнение JSP и поиск ресурсов внутри веб-приложения - PullRequest
2 голосов
/ 06 ноября 2011

В соответствии с требованиями проекта, мне нужно создать веб-приложение, которое при выполнении позволит некоторым пользователям загружать zip-файлы, которые похожи на небольшие приложения, и будут содержать .class-файлы, ресурсы (изображения, css, js, ...) и даже файлы lib. Этот zip-файл похож на военный файл.

Любой способ легко закодировать это? AFAIK Я думаю, что я знаю, как кодировать пользовательский ClassLoader для загрузки классов из zip-файла ( Java - Custom ClassLoader - пытается загрузить класс с использованием полного пути к файлу класса ) и даже кодировать поиск ресурсов при запросе браузером, но не знаю, как выполнить файлы JSP, которые будут внутри zip-файла, или загрузить файлы jar lib внутри zip-файла.

РЕДАКТИРОВАТЬ: веб-приложение должно управлять загруженными приложениями, и нет способа реализовать это, как указано ниже, потому что веб-приложениям для работы требуется «главное» веб-приложение. Также это «главное» веб-приложение позволяет управлять версиями приложений. Пользователь сможет загрузить новую версию, обновить ее и даже выполнить понижение версии, если новая версия начнет давать сбой.

Ответы [ 2 ]

1 голос
/ 07 ноября 2011

Нет простого способа сделать это. Это много работы. Классные загрузчики очень привередливые звери. Возможно, основная часть работы по созданию чего-то вроде Tomcat заключается в разгоне загрузчиков классов, остальное - просто настройка. И даже после всех этих лет у нас все еще есть проблемы.

Например, Tomcat очень агрессивно относится к тому, как он пытается выгрузить существующие веб-приложения, используя внутреннюю информацию о библиотеках классов Java, чтобы попытаться найти места для утечек в загрузчиках классов и т. Д. И, несмотря на их усилия, проблемы все еще существуют.

Последняя версия Glassfish имеет (или будет иметь) возможность создания версий приложений. Возможно, вам повезет, просто взломав код внутренней маршрутизации и сопоставления Tomcats для управления версиями.

Если вы работаете с EJB-контейнером, вы можете поместить свои основные службы в EJB-компоненты и позволить WAR-файлам общаться с ними (вы можете сделать это с помощью веб-служб в универсальном контейнере сервлетов, но многие EJB-контейнеры могут преобразовывать семантику Remote. в локальную семантику для вызовов в один и тот же контейнер).

Вы также можете посмотреть на OSGI. Это еще одна реальная проблема для управления, но она может быть достаточно детальной, чтобы даже дать вам управление версиями, но никто из ваших пользователей не захочет ее использовать. Я упоминал, что это реальная боль, чтобы справиться? Мы делаем это для динамической загрузки веб-контента и логики, но мы этого не делаем.

Если у вас все под контролем одной WAR, то лучше всего делать ставку на Java и вместо этого использовать язык сценариев. Вы склонны иметь немного больший контроль над средой выполнения сценариев, особенно если вы НЕ позволяете им получать доступ к произвольным классам Java.

С этим вы можете загружать любую полезную нагрузку, какую хотите, обрабатывать всю диспетчеризацию самостоятельно, используя статические ресурсы и логику (что означает, что вы можете обрабатывать аспект управления версиями). Используйте что-то вроде Velocity для своих страниц "JSP", а затем используйте Javascript или любой другой для логики.

Версионная среда может быть мучительной. Если вам не нужно делать это атомарно, это очевидно проще. Если вы можете позволить себе «простоя» (перевести v1 в автономный режим, а затем поднять v2), это будет намного проще. Если вы загружаете полное содержание каждой версии, это действительно легко. Моя система допускала постепенные изменения и имела семантику копирования при записи, так что это было намного сложнее. Но я действительно не хотел загружать несколько гигабайт медиа для каждой версии.

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

Вы получите огромную радость от повторного воплощения в жизнь солидного куска HTTP-протокола, что тоже всегда приятно, поскольку контейнер сервлетов на самом деле не предоставляет вам эту функциональность. То есть вы захотите сделать это, если хотите быть хорошим гражданином в Интернете. Вы всегда можете просто непрерывно проталкивать контент в горло клиентов, будьте прокляты кэширование и прокси.

0 голосов
/ 07 ноября 2011

Вы можете вручную создать WAR-подобные структуры внутри своего каталога веб-контейнера веб-контейнера и поместить туда классы, JAR и JSP.

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

В большинстве случаев веб-контейнеры считают любую папку, имеющую подпапку WEB-INF, содержащую действительный файл web.xml, веб-приложением.Вы можете ограничить доступ к этому новому веб-приложению, изменив его конфигурацию контекста, расположенную в META-INF / context.xml в случае Tomcat.

Управление горячим повторным развертыванием, политиками загрузчика классов и т. Д. Зависит от типа вашего веб-контейнера., но я надеюсь, что вы не хуже, чем Tomcat, который мог бы справиться со всем этим.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...