源码解析之访问osgi felix bundle中的文件和资源

Apache Felix

Apache Felix

根据osgi规范中api的定义目前访问bundle里面的文件和资源的方法有三种。本文以felix框架为例,解析一下osgi中访问bundle里面的文件和资源的方法,以及各方法的区别。

一. Bundle.getEntry(String name)

该方法只能从当前的bundle jar中获得文件和资源(包括jar中的所有文件,比如*.class、META-INF\MANIFEST.MF等)。该方法的返回值为java.net.URL,在使用这个url的时候不能将其转成File类型来读取文件内容,因为这个url不是一个普通的文件操作系统中的url,而是osgi容器中的一个抽象的url,其文件读取操作必须交由创建这个url时设置的URLHandlersBundleStreamHandler来处理。所以如下的代码是不能获取到文件和资源的:

可以看到,从bundle中获取的entry的文件路径不是一个真实意义上的路径,它只是一个osgi容器才认识的url,要对这个url处理就需要用如下的方式,见示例代码:

接下来,从felix的源码中看看为何只能用下面的方式,这要从这个url是如何创建的来看了,在BundleImpl.getEntry(String name)方法中进行追踪,可以看到这个url是由BundleRevisionImpl.createURL(int port, String path)方法产生的,其代码如下:

在追踪下这个BundleStreamHandler,可以发现它是在Felix框架初始化的时候给默认设置的。如此就明了了。这个url对应的资源其实不能算是一个具体的文件,至少在Felix框架中不是,Equinox可能可以通过其他的方式来用文件方式来读取bundle中的资源,详见stackoverflow的一个question《No access to Bundle Resource/File (OSGi)》

二. Bundle.getResource(String name)

该方法的返回值也是URL类型的,其使用方法和Bundle.getEntry(String name)方法相同,也不能把url.getFile()当做文件名来创建File对象,只能用openConnection().getInputStream()来读取文件和资源的内容。

这个方法查找资源的方式和之前一篇博客《osgi类加载顺序源码解析》相似,在bundle没有解析时(即不处于resolved状态时),直接从当前bundle中查找资源;如果已经解析,就按照类加载的优先级,优先从其他bundle的classpath下查找这个文件或资源,如果有就返回;如果没有,才从本地bundle中查找并返回。(当然如果要共享某个bundle中的资源文件,就需要export这个资源文件所在的包,而且要使用这个资源的bundle也需要import这个包才行)。详见源码:

利用这一点,可以和getEntry方法搭配使用,达到游刃有余的控制资源共享的效果。

三. Bundle.getDataFile(String filename)

该方法是从felix cache的当前bundle的data文件夹下获取得文件和资源。这个data文件夹与felix cache的目录结构有关。默认情况下felix cache文件夹下会为每个bundle创建一个文件夹,文件夹的名称为bundle0、bundle1、bundle2。。。。bundleN,其中bundle0是系统bundle。每个bundle文件夹下又会为每个bundle的revision创建一个文件夹,文件夹名称的前缀为version(比如:version0.0),另外bundle文件夹下还有一个bundle.info的文件,描述了bunlde的信息(如果bundleId、被安装的bundle的jar文件路径、时间戳等)。如下图所示:

felix-cache目录结构

felix-cache目录结构

 

默认情况下,每个bundle目录下都没有data文件夹,getDataFile方法一旦被调用,就会在felix cache的当前bundle文件夹下,创建名为data的文件夹(如果没创建则创建之,如果已创建过,则跳过),该方法的参数是文件的相对路径,这个相对路径都是相对于当前bundle的data文件夹的;该方法的返回值是File类型,与上两个api不同,这个file是一个真实存在的文件,是可以通过file.toString()得到的url直接定位的。可以这样使用这个api:

这个方法相当于是提供了一个便捷的方式来存储和获取每个bundle下的数据。其源码其实最终的调用的BundleArchive类的getDataFile方法,源码如下:

 

综合使用上述的三个api就可以比较方便的读取bundle的资源了。另外还有getEntryPaths(String path)、findEntries(String path, String filePattern, boolean recurse)、getResources(String name)等一次性获取多个资源的api,还有便于读取menifest.mf文件的api:getHeaders()、getHeaders(String locale)等。

Post Footer automatically generated by wp-posturl plugin for wordpress.



  1. 文件夹名称的前缀为version(比如:version0.0)
    ———-
    bundle每update一次,version0.0最后面的数字+1,
    每一个version0.0、version0.1等等,应该和BundleRevision概念相对应。
    同一个Bundle中可能并存多个Revision,但bundle.getEntry()总是访问最后一个revision中的资源。
    Revision如果没有被其他bundle使用的话,可能会被框架删除。

  2. bundle.getDataFile() 管理的文件,对于不同的BundleRevision是共享的。
    对Bundle进行Update动作不影响dataFile。
    但是如果bundlecache被清除,那么这些dataFile就都不存在了。
    ——————- 所以还没有找到一个合适的使用dataFile的场合。