Java IoC: распределенная конфигурация - PullRequest
Новая
       28

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

2 голосов
/ 01 сентября 2010

Я создаю приложение J2EE, в котором я хочу разрешить плагины.Я вполне убежден в совершенстве инфраструктуры IoC, поэтому у приложения будет один для управления службами.

Теперь я хочу разрешить добавление плагинов в виде простого JAR-файла, сброшенного в classpath + возможно, простого файла конфигурации для редактирования, чтобы активировать их, никоим образом не похожего на конфигурацию Spring XMLфайлы.

Большая часть архитектуры плагинов будет базироваться на стратегии / конвейере / цепочке шаблонов команд: например, лучший плагин для действия выбирается стратегией, несколько плагинов добавляют действия фильтрации к вводу пользователя благодаря конвейеруи так одно.

Итак, я хочу иметь возможность:

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

Первые 2 пункта довольно просты, с IoC или без.Последний вариант кажется более сложным без поддержки на уровне контейнера IoC, или, по крайней мере, необходимо выполнить много операций с каналом (как управлять обнаружением classpath / sevice, как управлять заказами на обслуживание в конвейере, когда контекстизменение (новые плагины), как управлять переопределением сервиса и т. д.).

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

Так что мне интересно:

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

Спасибо за любые советы!

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

Ответы [ 3 ]

0 голосов
/ 01 сентября 2010

Как только вы начнете сбрасывать jar-файлы и их зависимости, а затем выполните несколько итераций этого с разными плагинами и разными версиями зависимостей, вы начнете чувствовать боль, которой подвержены многие «контейнеры хоста приложения».
Одним из возможных решений этой проблемы является OSGi, хотя я отметил блог Tapestry, в котором освещаются недостатки подхода OSGi:
http://blog.tapestry5.de/index.php/2010/01/19/tapestry-ioc-modularization-of-web-applications-without-osgi/

0 голосов
/ 01 сентября 2010

Я не уверен, как это будет работать именно с тем, что вы хотите сделать, но основной механизм работы с плагинами Guice - Multibindings . То, как вы обрабатываете обнаружение плагинов, зависит от вас, но есть множество вариантов, включая сканирование пути к классам для реализаций интерфейсов плагинов, когда плагины предоставляют Module, который добавляет их реализацию к мультибиндерам, используя файл конфигурации, в котором перечислены классы реализации плагина и т. д.

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

0 голосов
/ 01 сентября 2010

Рассматривали ли вы взглянуть на решение Java EE 6 - CDI, реализация называется Weld на основе JBoss Seam - что может быть полезно?

...