有没有人使用Felix + ipojo做开发的？

0 0

有没有人使用Felix + ipojo做开发的？0

有没有人使用Felix + ipojo做开发的？

有的话，可以多交流下。

现在用Felix + ipojo感觉真寂寞啊

问题补充：发现 @Context(Source.INSTANCE) 注解无效。
反复跟踪源码，结果是 BundleContextHandler 在处理实例Context注入的时候，InstanceManager中压根还没有设置InstanceContext。
设置部分在ManagedType.InstanceSupport.addService(...)方法内的：

ComponentInstance instance = m_future.get().createComponentInstance(instanceDeclaration.getConfiguration());
if (instance instanceof InstanceBundleContextAware) {
   ((InstanceBundleContextAware) instance).setInstanceBundleContext(instanceDeclaration
                                        .getBundle().getBundleContext());
}

要命的是使用在前，设置在后... 后来查询到这事ipojo 1.12版本的BUG。

BUG编号：FELIX-4646
https://issues.apache.org/jira/browse/FELIX/component/12311164/?selectedTab=com.atlassian.jira.jira-projects-plugin:component-summary-panel

问题补充：本以为这是 BundleContextHandler 实现有误，所以，试着重新定义了一个新的注解 @InstanceBundleContext，提供了一个新的Handler。
但最终发现仅仅通过Handler，这个问题绕不过。
也许IPOJO需要调整 InstanceBundleContext的注入时机。

只能等ipojo的下一个版本了，不知道什么时候才会出来..现在是2014-10-15

问题补充：在GoGo控制台执行 update ** 命令，结果发现死锁。
要Update的bundle是通过 Install obr:*** 方式加载的。

发现控制台无反应后，用JConsole检查了一下，发现
LogListenerThread所在的线程和Gogo Shell所在线程发生死锁。

以前也偶尔发现过执行命令后无反应的现象，由于是在调试，所以就重启Felix，没有太在意。
这种死锁还是比较头疼的事情...

难道不能使用org.apache.felix.log-1.0.1日志模块吗？

问题补充：关于以ipojo为主要组件模型的系统启动时性能监测。

目前找到的一个办法是实现QueueListener，并且把实现类作为QueueListener的服务进行注册。

大概原理是 ipojo下的各种依赖关系基本都是通过事件回调形式发生的，
这些事件任务被ipojo丢到了一个事件队列中，依次触发执行；
(当然ipojo自身提供了同步的、异步的队列服务，缺省情况下，是由PreferenceQueueService丢到一个异步队列中执行)

ipojo的队列服务提供了队列监听器，并且任务在执行时，会进行统计任务执行时间（参考JobInfoCallable类）；QueueListener由ReplayQueueEventProxy进行触发。

问题补充：由于缺省情况下，ipojo的任务处理线程只开了一个（[ipojo]pool-1-thread-1这个线程），
上面的性能统计基本能用，如果有并发任务的话，统计时间就不准了。

OSGI