很多人一直在问 SpringSource Application Platform 究竟能为 Spring 应用程序做什么，使其在 OSGi 上运行良好，这超出了 OSGi 和 Spring Dynamic Modules 开箱即用的功能。Adrian 昨天的帖子重点介绍了一些一般性问题，现在我们来看一些细节。

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

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

其余但不太有趣的方面包括：JSP 支持、TLD 扫描、注解匹配和资源查找。总而言之，有一些相当多的问题需要解决才能使应用程序平稳部署。

加载时编织

加载时编织是支持的一项最棘手的功能。在基本层面上，它需要挂钩到 Equinox 的 ClassLoader，以便在 defineClass 调用期间可以附加和使用标准的 ClassFileTransformers。在此基础上，许多 LTW 的用法需要访问一个一次性的 ClassLoader，该 ClassLoader 可用于检查类型以决定在编织期间需要做什么，而不会影响实际的 ClassLoader。

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

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

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

类路径扫描

对于类路径扫描，主要问题是 Equinox 不暴露标准的 jar: 和 file: 资源。Platform 在中间放置了一个适配器，以便库可以看到它们期望的资源协议。这有一个很好的副作用，就是使**大量**第三方库能够工作——这不仅仅是类路径扫描的修复。

线程上下文类加载器管理

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

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

这只是 Platform 所解决问题的一小部分，但希望它能让您对 Platform 对 Spring Framework 用户意味着什么有所了解。