类加载器特技：OSGi代码生成.doc

类加载器特技：OSGi代码生成
把大型系统移植到OSGi架构上常常意味着解决复杂的类加载问题。这篇文章专门研究了面向这个领域最难问题的几个框架：有关动态代码生成的框架。这些框架也都是些超酷的框架：AOP包装器，ORM映射器以及服务代理生成器，这些仅仅是一些例子。
我们将按照复杂性增加的顺序考察一些类加载的典型问题，开发一小段代码来解决这些问题中最有趣的一个。即使你不打算马上写一个代码生成框架，这篇文章也会让你对静态定义依赖的模块运行时（如OSGi系统）的低级操作有比较深入的了解。
这篇文章还包括一个可以工作的演示项目，该项目不仅包含这里演示的代码，还有两个基于ASM的代码生成器可供实践。
类加载地点转换
把一个框架移植到OSGi系统通常需要把框架按照HYPERLINK"http://rinswind.blogspot.com/2009/07/osgi-go-forth-and-extend.html"extender模式重构。这个模式允许框架把所有的类加载工作委托给OSGi框架，与此同时保留对应用代码的生命周期的控制。转换的目标是使用应用bundle的类加载来代替传统的繁复的类加载策略。例如我们希望这样替换代码：
ClassLoaderappLoader=Thread.currentThread().getContextClassLoader();
ClassappClass=appLoader.loadClass("com.acme.devices.SinisterEngine");
...
ClassLoaderappLoader=...
ClassappClass=appLoader.loadClass("com.acme.devices.SinisterEngine");
替换为：
BundleappBundle=...
ClassappClass=appBundle.loadClass("com.acme.devices.SinisterEngine");
尽管我们必须做大量的工作以便OSGi为我们加载应用代码，我们至少有一种优美而正确的方式来完成我们的工作，而且会比以前工作得更好！现在用户可以通过向OSGi容器安装/卸载bundle而增加/删除应用。用户还可以把他们的应用分解为多个bundle，在应用之间共享库并利用模块化的其他能力。
由于上下文类加载器是目前框架加载应用代码的标准方式，我们在此对其多说两句。当前OSGi没有定义设置上下文类加载器的策略。当一个框架依赖于上下文类加载器时，开发者需要预先知道这点，在每次调用进入那个框架时手工设置上下文类加载器。由于这样做易于出错而其不方便，所以在OSGi下几乎不使用上下文类加载器。在定义OSGi容器如何自动管理上下文类加载器方面，目前有些人HYPERLINK"http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhancements"正在进行尝试。但在一个官方的标准出现之前，最好把类加载转移到一个具体的应用bundle。
适配器类加载器
有时候我们转换的代码有外部化的类加载策略。这意味着框架的类和方法接收明确的ClassLoader参数，允许我们来决定他们从哪里加载应用代码。在这种情况下，把系统转换到OSGi就仅仅是让Bundle对象适配ClassLoaderAPI的问题。这是一个经典的适配器模式的应用。
publicclassBundleClassLoaderextendsClassLoader{
privatefinalBundledelegate;

publicBundleClassLoader(Bundledelegate){
this.delegate=delegate;
}

@Override
publicClass<?>loadClass(Stringname)throwsClassNotFoundException{
returndelegate.loadClass(name);
}
}
现在我们可以把这个适配器传给转换的框架代码。随着新bundle的增减，我们还可以增加bundle跟踪代码来创建新的适配器——例如，我们可以“在外部”把一个Java框架适配到OSGi，避免浏览该框架的代码库以及变换每个单独的类加载场所。下面是将一个框架转换到使用OSGi类加载的示意性的例子：
...
Bundleapp=...
BundleClassLoaderappLoader=newBundleClassLoader(app);

DeviceSimulationFrameworksimfw=...
simfw.simulate("com.acme.devices.SinisterEngin