Другой osgi связывается с реализациями того же интерфейса - куда поместить тот интерфейс?
Я в настоящее время проверяю osgi (Spring DM) на новом приложении. Приложение должно смочь слушать события файловой системы. Сегодня я решил это с простым временем базирующийся poller, но когда Java 7 выпущен, я, вероятно, хочу заменить это реализацией основанной на 2 NIO.
До сих пор я смотрю на три пакета, два для реализаций файловой службы и один для бизнес-логики, использующей один из сервисов. Эти две реализации должны реализовать тот же интерфейс, таким образом, мой вопрос, куда поместить тот интерфейс? Размещение интерфейса в пакете, содержащем реализацию, заставило бы сервис зависеть от одного из своих потребителей.
Что было бы лучшим и большая часть подобного osgi способа структурировать это? До сих пор мой лучший выбор состоит в том, чтобы создать новый пакет "API", определяющий единые интерфейсы для реализаций.
1 ответ
Separete api-bundle, вероятно, лучший выбор. Это позволяет позже заменить реализацию пакета. Также с отдельным пакетом api вы можете заменить текущий пакет без необходимости перезагрузки потребителя.
Классы (и интерфейсы) распознаются по их имени и загрузчику классов. Таким образом, если вы поместите служебный интерфейс в тот же пакет, что и реализация, вы потеряете возможность горячей замены работающего пакета. Несмотря на то, что интерфейс имеет то же имя и идентичен во всех смыслах, недавно развернутый пакет имеет другой загрузчик классов => потребитель рассматривает интерфейс недавно развернутого пакета как новый класс, и его зависимости больше не выполняются.
Для дополнительная информация о совместимости и версиях сервисов (см. комментарии): http: //wiki.osgi. org / wiki / Service_Compatibility