类加载器特技:OSGi代码生成
2010-03-01 00:00:00 来源:WEB开发网我们将按照复杂性增加的顺序考察一些类加载的典型问题,开发一小段代码来解决这些问题中最有趣的一个。即使你不打算马上写一个代码生成框架,这篇文章也会让你对静态定义依赖的模块运行时(如OSGi系统)的低级操作有比较深入的了解。
这篇文章还包括一个可以工作的演示项目,该项目不仅包含这里演示的代码,还有两个基于ASM的代码生成器可供实践。
类加载地点转换
把一个框架移植到OSGi系统通常需要把框架按照extender模式重构。这个模式允许框架把所有的类加载工作委托给OSGi框架,与此同时保留对应用代码的生命周期的控制。转换的目标是使用应用bundle的类加载来代替传统的繁复的类加载策略。例如我们希望这样替换代码:
ClassLoader appLoader = Thread.currentThread().getContextClassLoader();
Class appClass = appLoader.loadClass("com.acme.devices.SinisterEngine");
...
ClassLoader appLoader = ...
Class appClass = appLoader.loadClass("com.acme.devices.SinisterEngine");
替换为:
Bundle appBundle = ...
Class appClass = appBundle.loadClass("com.acme.devices.SinisterEngine");
尽管我们必须做大量的工作以便OSGi为我们加载应用代码,我们至少有一种优美而正确的方式来完成我们的工作,而且会比以前工作得更好!现在用户可以通过向OSGi容器安装/卸载bundle而增加/删除应用。用户还可以把他们的应用分解为多个bundle,在应用之间共享库并利用模块化的其他能力。
由于上下文类加载器是目前框架加载应用代码的标准方式,我们在此对其多说两句。当前OSGi没有定义设置上下文类加载器的策略。当一个框架依赖于上下文类加载器时,开发者需要预先知道这点,在每次调用进入那个框架时手工设置上下文类加载器。由于这样做易于出错而其不方便,所以在OSGi下几乎不使用上下文类加载器。在定义OSGi容器如何自动管理上下文类加载器方面,目前有些人正在进行尝试。但在一个官方的标准出现之前,最好把类加载转移到一个具体的应用bundle。
赞助商链接