Java IoC: разпределена конфигурация

Създавам J2EE приложение, в което искам да разреша плъгини. Доста съм убеден в добротата на IoC рамката и така приложението ще има такава за управление на услуги.

Сега искам да разреша добавянето на добавки като обикновен JAR, пуснат в classpath + може би прост конфигурационен файл, който да редактирате, за да ги активирате, в никакъв случай нещо, което прилича на Spring XML конфигурационни файлове.

По-голямата част от архитектурата на плъгина ще се основава на шаблони на стратегия/тръбопровод/верига от команди: например най-добрият плъгин за действие се избира от стратегия, няколко плъгина добавят филтриращи действия към потребителски вход благодарение на конвейер и така един.

И така, искам да мога да:

  • дефиниране на сервизни интерфейси в основното приложение,
  • настройка на основна реализация за разширими услуги с избрания модел в основното приложение,
  • оставете приставките на трети страни да се регистрират в тези кукички.

Първите 2 точки са доста лесни, със или без IoC. Последният изглежда по-сложен без поддръжка на ниво контейнер на IoC или поне има много работа за вършене (как да управляваме откриването на класова пътека/услуга, как да управляваме поръчките за услуги в конвейера, когато промяна на контекста (нови плъгини), как да управлявате отмяната на услугата и т.н.).

Знам, че Tapestry5 е страхотен в това отношение[1], но не мога да намеря нищо наистина подходящо за Spring и Guice. И моята компания е по-скоро String/Guice, отколкото T5 (е, ако мога да покажа, че това е най-доброто решение...)

Така че се чудя:

  • ако съм пропуснал някаква очевидна документация;
  • ако моите изисквания са толкова специални;
  • ако IoC контейнер не е правилният инструмент за това и трябва да търся OSGi или нещо друго.

Благодаря за всякакви съвети!

[1] http://tapestry.apache.org/tapestry5.1/tapestry-ioc/configuration.html


person fanf42    schedule 31.08.2010    source източник


Отговори (3)


Не съм сигурен как ще работи това с точно това, което искате да направите, но основната механика на Guice за работа с приставки е Множествени обвързвания. Как ще се справите с откриването на плъгини зависи от вас, но има различни възможности за избор, включително сканиране на пътеката на класа за реализации на интерфейси на плъгини, като плъгините предоставят Module, което добавя тяхната реализация(ия) към мултисвързващия(ите), използване на конфигурация файл, който изброява класовете за изпълнение на плъгина и т.н.

Както споменава връзката, ще ви трябва OSGi, ако имате нужда от добавки, които да могат да се добавят по време на изпълнение без рестартиране.

person ColinD    schedule 31.08.2010
comment
А, страхотно, мисля, че беше точно това, което търсих и не го намерих. И така, има само Пролетта, лидерът, която не е такова нещо? Благодаря ! - person fanf42; 01.09.2010

Обмисляли ли сте да разгледате решението Java EE 6 - CDI, изпълнението е наречено Weld, базирано на JBoss Seam - което може да е полезно?

person Thorbjørn Ravn Andersen    schedule 31.08.2010

След като започнете да пускате буркани и техните зависимости и след това преминете през няколко итерации на това с различни добавки и различни версии на зависимости, тогава ще започнете да усещате болката, на която се поддават много „хост контейнери на приложения“.
Една възможна решението на този проблем е OSGi, въпреки че забелязах блог на Tapestry, подчертаващ капаните на подхода OSGi:
http://blog.tapestry5.de/index.php/2010/01/19/tapestry-ioc-modularization-of-web-applications-without-osgi/

person crowne    schedule 31.08.2010
comment
Бих се опитал да избегна OSGi, който е наистина сложен и на ниско ниво за това, от което се нуждая, по-специално без зареждане на плъгин по време на изпълнение. Статията ясно обобщава предимствата на T5 IoC в това отношение. Въпреки това, ще имам предвид, че OSGi ще бъде просто и продуктивно решение, някъде в бъдещето. - person fanf42; 01.09.2010