Как построить JSF/Facelets/Spring приложение из модулей с OSGi?

То, что вы хотите сделать, звучит выполнимо, но с некоторыми оговорками:

Слой представления: Во-первых, ваш слой представления звучит как немного набитый. Есть и другие способы модулирования компонентов JSF с помощью пользовательских компонентов, которые позволят избежать головной боли, связанной с попытками создать что-то столь же драматичное, как управляемые bean-компоненты с поздним связыванием.

Сами модули: Во-вторых, ваши модули не кажутся особенно модульными. Ваш первый маркерный список звучит так, как будто вы пытаетесь создать совместимые веб-приложения, а не модули как таковые. Мое представление о модуле состоит в том, что каждый компонент имеет четко определенную и более или менее дискретную цель. Подобно тому, как ex лежит в основе vi . Если вы идете по пути OSGi, то мы должны определить модульный вариант следующим образом: Модульный, для целей данного обсуждения, означает, что компоненты поддерживают горячую замену, то есть их можно добавлять и удалил , не нарушив работу приложения.

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

Сервлеты: Fuhgeddaboudit. Вы не можете поздно привязать сервлеты к веб-приложению до тех пор, пока не будет создана спецификация Servlet 3.0 (как указал Паскаль). Чтобы запустить отдельный служебный сервлет, вам нужно поместить его в собственное приложение.

Хорошо, хватит оговорок. Давайте подумаем, как это может работать:

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

Есть способы обойти это, используя условные включения и т.п. (например, ), но, как вы сказали, все становится немного сложным, когда ваш управляемый компонент loginBean существует в другом модуле, который, возможно, еще не был добавлен в приложение.Фактически, вы получите исключение сервлета, если этот loginBean не существует. Итак, что вы делаете?

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

Мне нужно воспользоваться моментом, чтобы указать, что я не так подхожу к этой проблеме. Нисколько. Учитывая что-то вроде простой страницы входа в систему или даже такой сложной, как биржевой график, я лично предпочел бы создать собственный компонент JSF. Но если требуется: «Я хочу, чтобы мои управляемые компоненты были модульными (т. Е. С возможностью горячей замены и т. Д.)», Это единственный известный мне способ заставить его работать. И я даже не совсем уверен, что он будет работать . Этот обмен электронной почтой предполагает, что это проблема, над которой разработчики JSF только начали работать.

Обычно я рассматриваю управляемые компоненты как часть уровня представления, и поэтому я использую их только для логики представления, а все остальное делегирую на уровень служб. На мой взгляд, создание позднего связывания управляемых bean-компонентов продвигает их из уровня представления в бизнес-логику.Есть причина, по которой все эти руководства так сфокусированы на сервисах: потому что большую часть времени вы хотите подумать о том, что потребуется вашему приложению, чтобы работать без головы, и насколько легко было бы «скинуть» ваше представление, если для Например, вы хотели, чтобы он работал со всеми его функциями на телефоне Android.

Но похоже, что многое из того, с чем вы работаете, - это сама по себе логика представления - например, необходимость замены в другом шаблоне представления. OSGi / Spring должны помочь,но вам понадобится что-то в вашем приложении, чтобы выбирать между доступными реализациями: в значительной степени то, для чего был создан OSGi Service Registry.

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

Что касается оставшихся вопросов:

Я изобретаю здесь велосипед? Есть ли стандартные решения для этого?

Да, немного. Я видел приложения, которые выполняют такие вещи, но вы, похоже, столкнулись с довольно уникальным набором требований.

Считаете ли вы, что OSGi является подходящей технологией для описанной задачи?

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

Является ли мой набросок приложения OSGI более или менее правильным?

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

Но не верьте мне на слово. Я нашел других материалов для чтения в этих местах.

И поскольку вы спрашиваете о Spring Slices, этого должно быть достаточно, чтобы вы начали . Вам понадобится клиент Git, и, похоже, вы будете обучаться работе с приложением, просматривая исходный код. И это очень ранний прототип кода.