很多人都在问SpringSource应用平台究竟为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框架用户的意义。