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

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

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

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

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

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

ок, спасибо за сноску. Давайте подумаем, как это может работа:

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

есть способы обойти это, используя условные includes и как (например, <c:if #{loginBean.notEmpty}>), но, как вы сказали, все становится немного волосатым, когда ваш управляемый loginBean существует в другом модуле, который, возможно, еще даже не был введен в приложение. Фактически, вы получите исключение сервлета, если этот loginBean не существует. Так что ты делаешь?

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

мне нужно воспользоваться моментом, чтобы указать, что это не так, как я бы подошел к этой проблеме. Нисколько. Учитывая что-то вроде простой страницы входа в систему или даже такой же сложный, как график акций, я лично предпочел бы создать пользовательский JSF деталь. Но если требование "я хочу, чтобы мои управляемые бобы были модульными (т. е. с возможностью горячей замены и т. д.)", Это единственный способ заставить его работать. И я даже не совсем уверен в этом!--4-->будет работа. этот обмен электронной почтой предполагает, что это проблема, над которой разработчики JSF только начали работать.

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

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

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

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

я изобретаю велосипед? Существуют ли стандартные решения для этого?

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

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

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

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

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

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