0

由于我们忘记处理的构造实例，我目前在 iPojo 泄漏方面遇到了很多麻烦。我认为这是使用 ipojo 工厂技术使用命令式实例化的一个不可避免的缺点：基本上，您可以通过调用来说明何时需要您的服务factory.createComponentInstance(config)，因此您有责任说明何时完成。这迫使我保留两个引用，一个用于我想要使用的服务，还有一个 iPojo 的引用ComponentInstance，这样当消费者完成时，它可以调用componentInstance.dispose(). 如果没有，那就有泄漏

在消费者不需要处理 iPojo 服务及其实例的生命周期的情况下，是否有一种更具声明性的方式来做到这一点？

为了简化我的用例，假设有一个带有按钮的 UI，每次按下按钮时，我都需要一个新的、唯一的 iPojo 服务实例。理想情况下，当实例超出范围时，该实例将被 GC 处理，而消费者无需执行任何操作

也许我的错误是将服务用作实例，但我有三个理由使用服务而不是普通类并调用new.

  1. 服务实现应该是可替代的
  2. 消费者应该依赖于一个接口，而不是一个实现/提供者，这不仅是因为#1，而且还因为依赖于具体的 impl 时会产生更多的传递依赖
  3. 服务 impl 本身有一些依赖项，我希望这些依赖项会被 iPojo 注入（依赖注入）。

作为第二个请求，是否有人知道使用 iPojo 的任何开源、真实（即不是虚拟、演示）项目，我可以将其用作 iPojo 的良好使用示例？

4

1 回答 1

1

您可能应该使用自定义的“创建策略”，而不是创建组件实例。因此，您将只有一个组件实例，但会管理多个“实现”实例（服务对象）。您决定何时创建和处置这些对象。有关http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/providing-osgi-services.html#service-serving-object-creation的更多信息.

关于使用 iPOJO 的项目，您可以查看依赖于 iPOJO 的 Wisdom Framework：http ://wisdom-framework.org（那里提供的代码：github.com/wisdom-framework/wisdom/）

于 2015-04-21T06:59:38.920 回答