类加载器特技：OSGi代码生成 - 编程入门网

增强类扩充了应用代码 － 应用可以直接调用生成的对象。例如，一个传递 给应用代码的服务代理对象就是这种增强类对象，它使得应用代码不必去跟踪一 个动态服务。简单的说，增加了一些AOP特征的包装器被作为原始对象的替代品 传递给应用代码。

增强类的生命始于字节数组byte[]，由你喜爱的类工程库（ASM，BCEL， CGLIB）产生。一旦我们生成了我们的类，必须把这些原始的字节转换为一个 Class对象，换言之，我们必须让某个类加载器对我们的字节调用它的 defineClass()方法。我们有三个独立的问题要解决：

类空间完整性 - 首先我们必须决定可以定义我们增强类的类空间。该类空间 必须“看到”足够多的类以便让增强类能够被完全链接。

可见性 - ClassLoader.defineClass()是一个受保护的方法。我们必须找到 一个好方法来调用它。

类空间一致性 - 增强类从框架和应用bundle混入类，这种加载类的方式对于 OSGi容器来说是“不可见的”。作为结果，增强类可能被暴露给相同类的不兼容 的版本。

类空间完整性

增强类的背后支持代码对于生成它们的Java框架来说是未公开的 - 这意味着 该框架应该会把该新类加入到其类空间。另一方面，增强类实现的接口或者扩展 的类在应用的类空间是可见，这意味着我们应该在这里定义增强类。我们不能同 时在两个类空间定义一个类，所以我们有个麻烦。

因为没有类空间能够看到所有需要的类，我们别无选择，只能创建一个新的 类空间。一个类空间等同于一个类加载器实例，所以我们的第一个工作就是在所 有的应用bundle之上维持一个专有的类加载器。这些叫做桥接类加载器，因为他 们通过链接加载器合并了两个类空间：

public　class　BridgeClassLoader　extends　ClassLoader　{ 　 private　final　ClassLoader　secondary; 　 public　BridgeClassLoader(ClassLoader　primary,　ClassLoader　 secondary)　{ 　　 super(primary); 　 } 　 @Override 　 protected　Class<?>　findClass(String　name)　throws　 ClassNotFoundException　{ 　　 return　secondary.loadClass(name); 　 } }

类加载器特技：OSGi代码生成(3)

现在我们可以使用前面开发的BundleClassLoader：

/*　Application　space　*/ 　 Bundle　app　=　... 　 ClassLoader　appSpace　=　new　BundleClassLoader(app); 　 /* 　　 *　Framework　space 　　 * 　　 *　We　assume　this　code　is　executed　inside　the　 framework 　　 */ 　 ClassLoader　fwSpace　=　this.getClass().getClassLoader (); 　 /*　Bridge　*/ 　 ClassLoader　bridge　=　new　BridgeClassLoader(appSpace,　 fwSpace);

这个加载器首先从应用空间为请求提供服务 - 如果失败，它将尝试框架空间 。请注意我们仍然让OSGi为我们做很多重量工作。当我们委托给任何一个类空间 时，我们实际上委托给了一个基于OSGi的类加载器 - 本质上，primary和 secondary加载器可以根据他们各自bundle的导入/导出（import/export）元数 据将加载工作委托给其他 bundle加载器。

此刻我们也许会对自己满意。然而，真相是苦涩的，合并的框架和应用类空 间也许并不够！这一切的关键是JVM链接类（也叫解析类）的特殊方式。对于JVM 链接类的工作有很多解释：

简短的回答：

JVM以一种细粒度（一次一个符号）的方式来做解析工作的。

冗长的回答：

当JVM链接一个类时，它不需

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!