OSGi笔记-几个原理问题

1.什么样的jar才能做为bundle

不是任何jar都可以作为一个bundle存在的，jar必须符合一定的规范才能作为bundle安装到OSGi里去。

规范就是在jar的MANIFEST.MF文件里必须加入一些OSGi元数据，比如Export-Package, Import-Package, Required-Bundle等等。

一般的jar里是没有这些信息的，所以通常都不能作为bundle，除非加上这些信息再打包一次。这样是很麻烦的，所以Spring帮我们做了这个事情，在http://ebr.springsource.com/repository/app/search里，应该大部分我们要用的jar都有了。

除了再次打包jar，另外一种方法就是在打包我们自己开发的程序的jar的时候，把依赖的jar的class目录也打进去，但是这样就失去bundle的意义了。

2.基于classloader的模块化最大好处

jmx也可以实现模块化，可以把一个一个的模块作为Mbean安装进去。OSGi又如何呢？java只有加载类，没有卸载类，所以一旦一个class被加载到jvm里，那么就没法移除了，除非这个classloader被移除。当这个classloader被垃圾回收走的时候，它加载的class也一并被收走了。 OSGi的好处除了类隔离（不同bundle类不相互可见，不同bundle里可以加载同一个类的不同版本）外，就是不管怎么折腾，安装，卸载，基于classloader的机制都能确保在bundle卸载后把系统里面的垃圾全部移除。

3.bundle的classloader的之间的关系

每个bundle都有自己的classloader，这些classloader是相互隔离的，是一种兄弟关系，他们都有共同的parent classloader，默认情况下，这个parent是jvm的classloader。这个parent可以通过配置指向其他的classloader。

想象在tomcat(6)里，它的classloader关系是这样的：

Bootstrap | System | Common / / Webapp1 Webapp2 ...

这个Bootstrp就是jvm的classloader，其实它包括两个，一个是加载java.*, javax.*之类的jvm自带的类，另一个加载jvm的/lib/ext目录下的类。

所以默认情况下，OSGi的bundle的classloader就和Tomcat的System classloader在同一级了，这样很多jar就没法在不同的app之间共享。 我们可以把parent设成webapp classloader，就可以实现共享了。

4.bundle之间的类怎么共享

如果一个类是一个util类，里面都是静态变量，静态方法。那这些静态变量在不同的bundle是共享同一份还是分别有自己的实例？ 答案是共享同一份，使用class的bundle是不会去把class加载到自己的bundle的，它只会通过源bundle的classloader去拿到Class实例，所以不管怎么样，一般情况，class在整个OSGi里也只会被加载一次。

5.引用的class什么时候失效

如果一个bundle有发布服务，只要这个bundle不在active状态，其他bundle就不能使用这个服务。

但是如果只是使用这个bundle导出的class，那只要它在resolved状态就可以了。而且，一旦引用class成功，之后就算源bundle已经关闭，卸载。引用的class还是继续有效的，源bundle的classloader不会被删除。除非执行一次refresh，这个时候class的引用才被解除。