源码解析之访问osgi felix bundle中的文件和资源
源码解析之访问osgi felix bundle中的文件和资源
根据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来处理。
从felix的源码中看看为何只能用下面的方式，这要从这个url是如何创建的来看了，在BundleImpl.getEntry(String name)方法中进行追踪，可以看到这个url是由BundleRevisionImpl.createURL(int port, String path)方法产生的，其代码如下：
1 private URL createURL(int port, String path) 2 { 3 // Add a slash if there is one already, otherwise 4 // the is no slash separating the host from the file 5 // in the resulting URL. 6 if (!path.startsWith("/")) 7 { 8 path = "/" + path; 9 } 10 11 try 12 { 13 return m_secureAction.createURL(null, 14 FelixConstants.BUNDLE_URL_PROTOCOL + "://" + 15 m_id + ":" + port + path, 16 getBundle().getFramework().getBundleStreamHandler()); 17 } 18 catch (MalformedURLException ex) 19 { 20 m_bundle.getFramework().getLogger().log( 21 m_bundle, 22 Logger.LOG_ERROR, 23 "Unable to create resource URL.", 24 ex); 25 } 26 return null; 27 }
在追踪下这个BundleStreamHandler，可以发现它是在Felix框架初始化的时候给默认设置的。如此就明了了。这个url对应的资源其实不能算是一个具体的文件，至少在Felix框架中不是，Equinox可能可以通过其他的方式来用文件方式来读取bundle中的资源。
二、Bundle.getResource(String name)
该方法的返回值也是URL类型的，其使用方法和Bundle.getEntry(String name)方法相同，也不能把url.getFile()当做文件名来创建File对象，只能用openConnection().getInputStream()来读取文件和资源的内容。
在bundle没有解析时（即不处于resolved状态时），直接从当前bundle中查找资源；如果已经解析，就按照类加载的优先级，优先从其他bundle的classpath下查找这个文件或资源，如果有就返回；如果没有，才从本地bundle中查找并返回。（当然如果要共享某个bundle中的资源文件，就需要export这个资源文件所在的包，而且要使用这个资源的bundle也需要import这个包才行）。详见源码：
1 URL getBundleResource(BundleImpl bundle, String name) 2 { 3 // 。。。。。。 4 5 // 如果这个bundle还没有解析就直接在本bundle中查找，否则委托给其他bundle查找 6 if (bundle.adapt(BundleRevision.class).getWiring() == null) 7 { 8 return ((BundleRevisionImpl) bundle.adapt(BundleRevision.class)) 9 .getResourceLocal(name); 10 } 11 else 12 { 13 return ((BundleWiringImpl) bundle.adapt(BundleRevision.class).getWiring()) 14 .getResourceByDelegation(name); 15 } 16 }
利用这一点，可以和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目录结构
默认情况下，每个bundle目录下都没有data文件夹，getDataFile方法一旦被调用，就会在felix cache的当前bundle文件夹下，创建名为data的文件夹（如果没创建则创建之，如果已创建过，则跳过），该方法的参数是文件的相对路径，这个相对路径都是相对于当前bundle的data文件夹的；该方法的返回值是File类型，与上两个api不同，这个file是一个真实存在的文件，是可以通过file.toString()得到的url直接定位的。
这个方法相当于是提供了一个便捷的方式来存储和获取每个bundle下的数据。其源码其实最终的调用的BundleArchive类的getDataFile方法，源码如下：
1 public synchronized File getDataFile(String fileName) throws Exception 2 { 3 // Do some sanity checking. 4 if ((fileName.length() > 0) && (fileName.charAt(0) == File.separatorChar)) 5 { 6 throw new IllegalArgumentException( 7 "The data file path must be relative, not absolute."); 8 } 9 else if (fileName.indexOf("..") >= 0) 10 { 11 throw new IllegalArgumentException( 12 "The data file path cannot contain a reference to the \"..\" directory."); 13 } 14 15 // Get bundle data directory. 16 File dataDir = new File(m_archiveRootDir, DATA_DIRECTORY); 17 // Create the data directory if necessary. 18 if (!BundleCache.getSecureAction().fileExists(dataDir)) 19 { 20 if (!BundleCache.getSecureAction().mkdir(dataDir)) 21 { 22 throw new IOException("Unable to create bundle data directory."); 23 } 24 } 25 26 // Return the data file. 27 return new File(dataDir, fileName); 28 }
综合使用上述的三个api就可以比较方便的读取bundle的资源了。另外还有getEntryPaths(String path)、findEntries(String path, String filePattern, boolean recurse)、getResources(String name)等一次性获取多个资源的api，还有便于读取menifest.mf文件的api：getHeaders()、getHeaders(String locale)等。
