OSGi - Насколько зрела эта технология? - PullRequest
14 голосов
/ 02 декабря 2009

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

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

Заранее спасибо!

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

РЕДАКТИРОВАТЬ 2: Я в принципе немного неясен относительно следующего:

  • Будет ли 'shareable-bundle' (содержащий веб-ресурсы для совместного использования) упакован .war. Если да, то откуда будет сформирован окончательный веб-контекст, так как этот пакет снова будет доступен для основного веб-приложения? Я ожидаю, что окончательный веб-контекст будет сформирован из слияния «shareable-bundle» и «основного» веб-приложения. Произойдет ли это автоматически? Есть идеи?

Ответы [ 4 ]

7 голосов
/ 02 декабря 2009

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

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

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

6 голосов
/ 02 декабря 2009

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

3 голосов
/ 02 декабря 2009

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

Если вы хотите прочитать об этом, вы должны проверить Модульная 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.

1 голос
/ 02 декабря 2009

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

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

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

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

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

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

  2. регистрация ресурсов (файлов и т. Д.) По URL-адресам.

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

...