很多人都在问，SpringSource Application Platform 究竟为 Spring 应用做了什么，使其在 OSGi 下运行良好，除了 OSGi 和 Spring Dynamic Modules 可以直接提供的功能之外。Adrian 昨天的文章重点介绍了一些常见问题，现在让我们看看其中的一些细节。

在 OSGi 上运行 Spring 应用最具挑战性的三个方面是

• 加载时织入
• 类路径扫描
• 线程上下文类加载器管理

其余但不太重要的问题包括：JSP 支持、TLD 扫描、注解匹配和资源查找。总而言之，需要解决大量问题才能使应用程序顺利部署。

加载时织入

加载时织入是最难支持的功能之一。 在基本层面上，它需要连接到 Equinox ClassLoader，以便可以在 defineClass 调用期间附加和使用标准 ClassFileTransformers。 除此之外，LTW 的许多用途都需要访问一次性的 ClassLoader，该类加载器可用于检查类型，以确定在不影响实际 ClassLoader 的情况下在织入期间需要发生的事情。

实际上，这种基本级别的支持相对容易实现。 困难在于，当织入由一个 bundle 中的类驱动，而另一个 bundle 中的类需要被织入时。 这在企业应用程序中非常常见，其中一个 bundle 包含域实体，而另一个 bundle 包含使用 JPA EntityManager 的类型。 该平台通过确保应用程序中的所有 bundle 都可以使用适当的 ClassFileTransformers 进行编织来处理此复杂性。

当您开始将编织传播到其他 bundle 时，您确实需要知道何时停止。 如果您只是将编织应用于所有 bundle，那么应用程序将会相互干扰。 该平台通过显式地限定编织范围来防止这种情况发生，使其仅适用于应用程序中的模块。

LTW 的另一个问题是它使刷新变得复杂。 刷新 bundle 时，OSGi 将刷新所有依赖于它的 bundle。 这意味着，在我上面给出的示例中，刷新域 bundle 将导致 EntityManager bundle 被刷新。 但是，刷新 EntityManager 不会刷新域 bundle，这意味着编织可能不同步。 该平台通过将刷新传播到受编织影响的其他 bundle 来处理此问题。

类路径扫描

对于类路径扫描，主要问题是 Equinox 不公开标准 jar: 和 file: 资源。 该平台在中间放置一个适配器，以便库看到它们期望的资源协议。 这有一个很好的副作用，可以使很多第三方库工作 - 它不仅仅是类路径扫描的修复程序。

线程上下文类加载器管理

许多第三方库使用线程上下文 ClassLoader 来访问应用程序类型和资源。 OSGi 中的每个 bundle 都有自己的 ClassLoader，因此，在任何时候，只有一个 bundle 可以作为线程上下文 ClassLoader 公开。 这意味着，如果第三方库需要查看分布在多个 bundle 中的类型，它将无法按预期工作。

该平台通过创建一个 ClassLoader 来解决此问题，该类加载器导入应用程序中每个模块的所有导出的包。 然后，此 ClassLoader 作为线程上下文 ClassLoader 公开，使第三方库能够查看应用程序中的所有导出类型。

这只是平台解决的一小部分问题，但希望它可以让您了解该平台对 Spring Framework 用户的意义。