Расширение веб-приложений Java с помощью плагинов

Question

У меня есть веб-приложение, которое превратилось в неуправляемый беспорядок.

Я хочу разделить его на общую часть «фреймворка» (которая по-прежнему включает веб-материалы, такие как страницы и изображения) и несколько модулей, которые добавляют дополнительную функциональность и экраны.Я хочу, чтобы этот рефакторинг также был полезен в качестве системы плагинов для сторонних расширений.

Все модули должны быть отдельной единицей развертывания, в идеале — файлом war или jar.

Я пытался просто создать несколько обычных военных файлов, но Tomcat хранит (согласно спецификации сервлета) эти военные файлы полностью отдельно друг от друга, так что они, например, не могут совместно использовать свои классы.

Мне нужны плагины, чтобы видеть «основной» путь к классам.

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

Я хотел бы сохранить полное разделение между самими плагинами (если они не указывают зависимости) и любыми другими несвязанными веб-приложениями, которые могут работать на том же Tomcat.

Я бы хотел, чтобы они располагались под «основным» префиксом URL-адреса приложения, но это не обязательно.

Я хотел бы использовать Tomcat (большие архитектурные изменения должны быть согласованы со слишком большим количеством людей), а также услышать о чистом решении в мире EJB или OSGi, если таковое имеется.

Answer 1

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

Answer 2

Взгляните на портлеты Java - http://developers.sun.com/portalserver/reference/techart/jsr168/ - в двух словах, спецификация, которая обеспечивает взаимодействие между автономными веб-приложениями j2ee.

РедактироватьЯ забыл упомянуть, что портлеты в значительной степени не зависят от платформы, поэтому вы можете использовать Spring для родительского приложения, а отдельные разработчики могут использовать в своих портлетах все, что захотят.

Answer 3

Рассматривали ли вы использование maven для разделения ваших проектов, а затем разрешаете ли они зависимости между WAR и JAR? В конечном итоге вы получите дублирование библиотек между WAR-ами, но только там, где это необходимо (и это не должно быть проблемой, если вы не попадаете в какое-то забавное занятие загрузчика классов).

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

Если вы хотите сохранить вещи в одном и том же веб-приложении (скажем, ROOT), вы можете создать прокси-веб-приложение, которое будет перенаправлено на соответствующее другое веб-приложение за кулисами для пользователя, чтобы сделать его относительно прозрачным?

Answer 4

Ваша основная проблема заключается в том, чтобы сосредоточиться на физических, статических ресурсах системы, а остальные - просто, по сути, баночки.

WAR в Tomcat разделены отдельными загрузчиками классов, но также они разделены на уровне сеанса (каждый WAR является отдельным веб-приложением и имеет свое собственное состояние сеанса).

В Glassfish, если WAR-файлы были объединены в EAR, они бы совместно использовали загрузчики классов (GF использует пространство загрузчика плоских классов в EAR), но все равно имели бы отдельное состояние сеанса.

Кроме того, я не уверен, что вы можете выполнить " пересылку " на другую войну на сервере. Проблема заключается в том, что перенаправители используют относительный URL-адрес к корню веб-приложения, и у каждого веб-приложения есть свой собственный корень, поэтому вы просто не можете "добраться отсюда". Вы можете перенаправить, но это не то же самое, что переадресация.

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

Скорее, я думаю, что горячим советом является создание "ассемблера" утилита, которая берет ваши отдельные модули и "объединяет" их в одном веб-приложении. Он может объединять их web.xml, их содержимое, нормализовать jar-файлы и классы и т. Д.

WAR - это особенность и ошибка в мире Java. Я люблю их, потому что они действительно делают развертывание скомпилированных приложений " Перетаскиванием " с точки зрения их установки, и эта функция используется гораздо больше, чем то, с чем вы сталкиваетесь. Но я чувствую твою боль. У нас есть общее «ядро» фреймворк, который мы разделяем между приложениями, и мы должны постоянно объединять его, чтобы поддерживать его. Мы написали это, но это все еще немного болезненно.

Answer 5

«Кроме того, я не уверен, можно ли выполнить «пересылку» на другую WAR на сервере.Проблема в том, что переадресация использует относительный URL-адрес корня веб-приложения, а каждое веб-приложение имеет свой собственный корень, поэтому вы просто «не можете попасть туда отсюда».Вы можете перенаправить, но это не то же самое, что направить вперед».

Вы можете перейти к другой WAR, если эта WAR позволяет кому-то это сделать.

стеклянная рыба и несколько ВОЙН УХА:в этом есть смысл.

Если вы поместите классы MAIN в общий CLASSPATH tomcat, вы сможете поместить свои отдельные ПЛАГИНЫ в отдельные файлы WAR.

Главное приложение также может быть частью сервлета TOMCAT, определенного в файле server.xml.Это может быть ГЛАВНЫЙ СЕРВЛЕТ, и все остальные WAR-файлы могут управляться этим главным сервлетом.

Имеет ли это смысл ?

БР,
~А

Answer 6

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

Затем ваше основное приложение настраивается с использованием URL-адреса веб-приложения (плагина), которое предоставляет услугу.

Преимущество, на мой взгляд, двоякое:

• Вы получаете хороший, чистый, отзываемый API между двумя войнами, а именно сообщения SOAP/XML
• Вы можете обновить один плагин без необходимости испытывать регрессионное тестирование всего вашего приложения

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

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

Answer 7

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

Теперь, как вы сказали, предпочтительный способ сделать это с помощью файла WAR или JAR. Проблема с файлом WAR в том, что вы не можете развернуть его как плагин в существующем приложении. Tomcat развернет его как отдельный веб-контекст. Не желательно

Другой вариант - это JAR-файл и написать собственный код для копирования этого JAR-файла в папку WEB-INF / lib и загрузки классов в существующий загрузчик классов. Проблема в том, как развернуть не-Java-файлы, такие как JSP или файлы конфигурации. Для этого существует два решения: Используйте шаблоны скорости вместо JSP (b.), Чтобы написать собственный код для чтения JSP из пути к классам вместо пути к контексту.

Модули OSGI или Spring Dynamic хороши, но в настоящее время они кажутся мне слишком сложными. Я еще раз посмотрю на это, если почувствую это.

Я ищу простой API, который может позаботиться о жизненном цикле плагина и все же иметь возможность использовать JSP в моем упакованном файле JAR.

Может быть, вы можете использовать un jar для плагина во время развертывания и копировать файлы в нужные каталоги.

Answer 8

На самом деле нет ничего лучше OSGI, если вы думаете о разделении приложения на отдельные модули. Взгляните на пример с Greenpages. Вы можете создать родительский модуль (ядро), в который будут включены файлы jar, необходимые для вашего приложения.

Если вы что-то знаете о компонентном программировании, вы скоро обнаружите, что модули OSGI ведут себя как интерфейсы, где вам нужно показать, что вы будете использовать в других модулях. Это довольно просто, когда вы понимаете. В любом случае, это также может быть очень больно, когда вы узнаете, как использовать OSGI. У нас были проблемы с использованием JSON, поскольку версия Джексона, которую мы добавили в модуль в качестве jar-файла, была переопределена другим jar-файлом, который содержался в основных модулях Spring. Вы всегда должны дважды проверить, какая версия jar загружена для ваших нужд.

К сожалению, даже подход OSGI не решает то, что мы ищем. Как расширить постоянную модель и существующие формы во время выполнения.