SpringSource Application Platform 的主要优势之一是其能够根据需要配置依赖项。这样做的好处有两个：它确保平台的内存占用尽可能小，并且允许应用程序部署而无需将所有依赖项封装在一个单一的部署单元中，例如 WAR 文件。为了利用这些功能，您需要了解平台的配置存储库，而这篇博文的目的正是提供这些知识。

配置存储库在哪里以及它是如何工作的？

默认情况下，平台的配置存储库可以在安装根目录下的 repository 目录中找到： 如您所见，这里有三个主要目录：bundles、installed 和 libraries。 installed 用于平台的内部使用，因此我们将重点关注这里的 bundles 和 libraries 目录。每个目录包含许多子目录，用于分离不同类型的依赖项

• ext 包含与平台一起提供的外部依赖项，但不是平台本身的一部分。
• subsystems 包含构成平台的所有子系统。
• usr 最初为空，旨在包含用户添加的依赖项，即应用程序依赖的任何内容，而这些内容不是由平台提供的。

平台在初始启动期间搜索 repository 目录结构中的捆绑包和库。我将在本文的后面讨论如何配置此搜索。当在存储库中找到捆绑包和库时，其符号名称、导出的包等详细信息将添加到存储库的内存中索引中。扫描完成后，内存索引将缓存到磁盘中。在开发过程中，我们优先考虑最大程度地减少平台的启动时间。此缓存允许平台在启动期间节省一些时间：除非它检测到存储库的内容已更改，否则它可以跳过扫描。

运行时配置

在普通的 OSGi 环境中，捆绑包的依赖项只能由已安装在环境中的其他捆绑包满足。例如，安装并启动导入 org.apache.commons.dbcp 包的捆绑包将失败，除非已安装导出该包的捆绑包。这对用户来说可能很麻烦，因为他们必须手动安装捆绑包的所有依赖项。幸运的是，SpringSource Application Platform 通过根据需要动态安装依赖项来显著改善了这一点。

当平台启动已部署的应用程序时，其捆绑包将安装到 Equinox 中。然后，平台会要求 Equinox 提供所有捆绑包未满足的依赖项列表，并尝试满足这些依赖项。让我们通过一个简单的示例场景来分析此过程

1. 平台将导入 org.apache.commons.dbcp 的捆绑包安装到 Equinox 中。
2. 平台要求 Equinox 提供捆绑包未满足的依赖项，并被告知无法满足对 org.apache.commons.dbcp 的导入。
3. 平台在其配置存储库索引中搜索导出 org.apache.commons.dbcp 的捆绑包
4. 平台将导出 org.apache.commons.dbcp 的捆绑包安装到 Equinox 中
5. 在满足原始捆绑包的依赖项后，平台成功启动了原始捆绑包。

我们希望这将使我们用户的体验更加轻松：只要应用程序的依赖项可供平台使用，您就可以简单地部署应用程序并开始使用！无需费力地手动安装应用程序的所有依赖项。此过程的一大优点是仅在需要时才安装依赖项。您可以将任意数量的捆绑包添加到配置存储库中，而对平台的内存占用几乎没有影响。

如果平台无法从其存储库中满足依赖项，则会生成一条详细说明无法满足的依赖项的日志消息。有了这些信息，您可以使用 SpringSource Enterprise Bundle Repository 获取所需的内容。我们希望存储库提供尽可能完整的捆绑包集：如果您需要某个依赖项但它不可用，请 告知我们。

将项目添加到配置存储库

因此，您已下载了一个或两个依赖项，现在您想将其添加到平台中。您只需将其复制到存储库中的相应目录即可。例如，新的捆绑包通常会添加到 repository/bundles/usr 目录中，新的库描述符通常会添加到 repository/libraries/usr 目录中。

如上所述，平台使用在启动期间填充的配置存储库的内存中索引。此外，平台还将在每次部署应用程序时检查其对存储库的视图是否是最新的。当您要安装具有新依赖项的应用程序时，只需将依赖项复制到存储库中的相应位置，然后部署您的应用程序。在部署处理期间，平台将注意到存储库已更新，并将刷新其对存储库的视图。这意味着您无需每次要安装具有新依赖项的应用程序时都花费时间重新启动平台。

在安装之间共享配置存储库

可以轻松配置平台在配置存储库中搜索项目的位置以满足您的需求。例如，多个平台实例可以共享配置存储库的一部分或全部，因此您无需浪费精力在平台安装之间维护重复的捆绑包集。

在创建配置存储库时平台扫描的位置可以在 config/platform.config 文件中配置。在没有特定配置的情况下使用的默认配置为

"provisioning" : {
    "searchPaths": [ 
        "repository/bundles/subsystems/{name}/{bundle}.jar",
        "repository/bundles/ext/{bundle}",
        "repository/bundles/usr/{bundle}",
        "repository/libraries/ext/{library}",
        "repository/libraries/usr/{library}"
    ]
}

平台将任何相对路径解释为相对于其安装根目录，也支持绝对路径。花括号内的搜索路径中的条目只是通配符，例如，子系统搜索路径 repository/bundles/subsystems/{name}/{bundle}.jar 将查找 subsystems 目录的任何直接子目录中以 .jar 结尾的文件。

希望您能看到，在平台之间共享配置存储库的一部分或全部是一个简单的更改。例如，要使平台搜索文件系统根目录中名为 shared-bundles 的目录以及它自己的 subsystems 和 ext 目录，您只需将以下 JSON（JavaScript 对象表示法）代码段添加到 platform.config 文件中即可

"provisioning" : {
    "searchPaths": [
        "repository/bundles/subsystems/{name}/{bundle}.jar",
        "repository/bundles/ext/{bundle}",
        "/shared-bundles/{bundle}",
        "repository/libraries/ext/{library}",
        "repository/libraries/usr/{library}"
    ]
}

通过使用此配置配置两个或多个平台安装，可以使它们共享 /shared-bundles 中的捆绑包。通过将所有搜索路径配置为指向共享位置，可以轻松地更进一步，因此您根本不需要管理每个平台的配置存储库。

下一步是什么？

我们计划通过提供一些工具或脚本，简化从同一组二进制文件中运行多个平台实例的操作。这些脚本将为您完成大部分工作，提供一个合理的默认配置，然后您可以对其进行调整以满足您的特定需求。

我们还打算通过允许平台配置为在尝试满足依赖项时可选地搜索远程存储库，来结合平台的按需配置和 SpringSource Enterprise Bundle Repository 的强大功能。如果在远程存储库中找到依赖项，平台将自动处理其下载和安装。希望这将使开发人员的生活更加轻松，尤其是在应用程序开发的初始阶段，因为定期会添加新的依赖项。

在我们处理上述增强功能和平台本身时，我们很乐意听到您的建议：请随时评论此博客文章、提交 JIRA 或在我们的 论坛 上发帖。