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

类加载器特技：OSGi代成 把大型系OSGi架构上常常意味着解决AOP包装器，ORM映射器以及服。 我们将按照复杂性增加的顺序考察一些类加载的典型问题，开发一小段代码来解决这些问题中最有趣的一个。即使你不打算马上写一个代码生成框架，这篇文章也会让你对静态定义依赖的模块运行时（如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。 适配器 有ClassLoader 参数，允OSGi就Bundle对象适配ClassLoader API的 public class BundleClassLoader extends ClassLoader { private final Bundle delegate; public BundleClassLoader(Bundle delegate) { this.delegate = delegate; } @Override public Class? loadClass(String name) throws ClassNotFoundException { return delegate.loadClass(name); } } 现在我们可以把这个适配器传给转换的框架代码。随着新bundle的增减，我bundle跟踪代 —— 例如，我“在外部”把一个Java框架适配到OSGi，避免OSGi类加载的示意性的例子： ... Bundle app = ... BundleClassLoader appLoader = new BundleClassLoader(app); DeviceSimulationFramework simfw = ... simfw.simulate(com.acme.devices.SinisterEngine, appLoader); ... 桥接类加载器 许多有趣的Java框架的客增enhancement）。通常，增 增 － AOP特征的包装器被作 增byte[]，由你喜ASM，BCEL，CGLIB）一个ClassdefineClass()方法。我 类空间完整性 - 首先我“看到”足 可 - 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); } } 现在我们可以使用前面开发的BundleClassLoader： /* Application