Создание и управление экземпляром iPojo

Question

В настоящее время у меня много проблем с утечками iPojo из-за сконструированных экземпляров, которые мы забываем утилизировать. Я рассматриваю это как неизбежный недостаток использования императивной реализации с использованием техники ipojo Factory: в основном вы говорите, когда вам нужен сервис, звоня factory.createComponentInstance(config)так что вы обязаны сказать, когда вы закончите с этим. Это заставляет меня сохранять две ссылки, одну для службы, которую я хочу использовать, а также другую из iPojo ComponentInstance так что, когда потребитель сделан, он может позвонить componentInstance.dispose(), Если нет, то есть утечка

Есть ли более декларативный способ сделать это, когда потребителю не нужно обрабатывать жизненный цикл сервиса iPojo и его экземпляра?

Чтобы упростить мой сценарий использования, представьте, что есть пользовательский интерфейс с кнопкой в ​​нем, и каждый раз, когда кнопка нажимается, мне нужен новый, уникальный экземпляр службы iPojo. В идеале, экземпляр должен быть GC'd, когда он выходит из области видимости, без необходимости что-либо делать потребителю

Может быть, моя ошибка заключается в использовании сервисов в качестве экземпляров, но у меня есть три причины использовать сервис вместо обычного класса и вызова new,

1. Услуга должна быть заменяемой
2. Потребитель должен зависеть от интерфейса, а не от реализации / провайдера, не только из-за #1, но и из-за тонны более транзитивных зависимостей, получаемых в зависимости от конкретной импликации.
3. У службы impl есть некоторые зависимости, которые, я надеюсь, будут внедрены iPojo (внедрение зависимостей).

В качестве второго запроса, кто-нибудь знает о каких-либо реальных (то есть не фиктивных) демонстрационных проектах с открытым исходным кодом, использующих iPojo, которые я могу использовать в качестве примера хорошего использования iPojo?

Answer 1

Вместо создания экземпляра компонента вы, вероятно, должны использовать собственную "стратегию создания". Таким образом, у вас будет только один экземпляр компонента, но с несколькими управляемыми экземплярами (объектами службы) реализации. Вы сами решаете, когда эти объекты будут созданы и удалены. Более подробная информация на http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/providing-osgi-services.html,

О проекте, использующем iPOJO, вы можете взглянуть на Wisdom Framework, который опирается на iPOJO: http://wisdom-framework.org/ (код доступен здесь: github.com/wisdom-framework/wisdom/)