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

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

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

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

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

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

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

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

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

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

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

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

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

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

Glassfish и несколько WAR-ов в EAR: в этом есть смысл.

Если вы поместите классы MAIN в общий CLASSPATH tomcat, вы можете поместить свои отдельные PLUGIN в отдельные файлы WAR.

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

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

BR,
~ А

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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