OSGi - Насколько зрелой эта технология?

У меня есть требование, когда мне нужно поделиться некоторыми веб-ресурсами (jsp, html, js, images, css и т.д.) в разных Spring приложениях Struts 2. И для этого можно использовать OSGi?

  • Может кто-нибудь дать некоторые указания о том, как достичь этого с помощью OSGi?
  • И во-вторых, я хочу знать, что OSGi достаточно зрело, чтобы использоваться в производственных приложениях?

Спасибо заранее!

EDIT: Я прошел через этот пост и кажется, что люди могут делиться веб-сайтом через веб-приложения. Единственное различие заключается в том, что они сделали это с помощью Spring MVC. Я хочу знать, может ли это быть достигнуто и с приложениями Struts2?

РЕДАКТИРОВАТЬ 2: В основном я не понимаю, о чем следующее:

  • Будет ли "совместно используемый пакет" (содержащий общие ресурсы Интернета) быть .war. Если да, то откуда будет создан окончательный веб-контекст, так как этот пакет снова будет использоваться совместно с основным "сетевым" приложением? Я ожидаю, что окончательный веб-контекст будет сформирован из-за слияния "совместного пакета" и "основного" веб-приложения. Это произойдет автоматически? Любые идеи?

Ответы

Ответ 1

В то время как OSGI может быть решением, это может быть немного избыточным (и, как заметил Божо, вам понадобится контейнер, поддерживающий OSGI). Возможно, посмотрите на Как распределить ресурсы между проектами в Maven для других опций:

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

EDIT: ответить на комментарий от OP. Да, идея создать сборку разделяемых веб-ресурсов и использовать плагин maven-dependency, чтобы вытащить и распаковать сборку в проектах "ресурс-потребитель". Все это объяснено и подробно описано в сообщении в блоге, упомянутом выше. Дайте мне знать, если что-то неясно в нем.

Ответ 2

OSGi используется в Eclipse, GlassFish, ServiceMix (и других), которые являются зрелыми программными продуктами. Однако они очень специфичны по своему характеру, и мое личное мнение заключается в том, что OSGi не совсем подходит для проектов общего типа. Насколько я знаю (кто-то меня исправляет, если есть новости в этой области), если вы хотите использовать OSGi с веб-приложениями, вам понадобится контейнер сервлетов OSGi. Кроме того, размещение ресурсов (html, js, images) в пакетах OSGi может быть проблематичным.

Ответ 3

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

Если вы хотите прочитать об этом, вы должны проверить Modular Java от Крэйга Уэллса, поскольку он дает неплохие OSGi в отношении Spring Framework.

Что касается совместного использования ресурсов, вы можете посмотреть в EAR-пакет. Я успешно использовал это для развертывания нескольких файлов WAR с общим набором ресурсов (например, сжатой версией Dojo).

Например, EAR может выглядеть так:

 ear-file/proj1
 ear-file/proj2
 ear-file/config
 ear-file/lib
 ear-file/resources
 ear-file/META-INF
 ear-file/APP-INF

Вы также можете прочитать в потоке .war vs .ear файл из предыдущего сообщения stackoverflow.

Ответ 4

Я не слишком знаком с Struts (или Spring MVC, если на то пошло), но вы можете посмотреть SpringSource dm Server. Он основан на Equinox, контейнере OSGi, используемом Eclipse, и пакетном Apache Tomcat (а также фреймворке Spring).

С сервером SpringSource каждый военный файл развертывается более или менее традиционно, но может обращаться к ресурсам (классам, сервисам и т.д.) через обычные механизмы OSGi. Эти механизмы основаны на загрузчиках классов классов OSGi, что может быть проблематичным для совместного использования файловых ресурсов, таких как jsps, html, css и т.д. Это может сработать, если у вас есть что-то похожее на DefaultServlet, которое отображает вещи от загрузчика классов, а не от файловой системы. (Или, черт возьми, я мог бы сделать это более сложным, чем мне нужно.)

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

Первый ответ на вопрос модульные веб-приложения выглядит действительно интересным, хотя и не применимым непосредственно к серверу SpringSource, поскольку он не предоставляет OSGi HttpService. Я считаю, что недавняя работа по спецификации предприятия OSGi 4.2 направлена ​​также на подход развертывания сервера SpringSource-war-files-as-OSGi-bundles.

В ответ на ваш вопрос EDIT 2, если я правильно его понимаю, "веб-контекст" в этом ответе будет построен динамически используя HttpService, который является интерфейсом, который предоставляет методы для

  • регистрировать сервлеты по URL-адресам и

  • регистрировать ресурсы (файлы и т.д.) по URL-адресам.

Так как эти операции обрабатываются динамически, нет необходимости в явном объединении битов веб-контекста.