我们本周在SpringOne Americas 大会上宣布了一款名为SpringSource tc Server 的新产品。SpringSource tc Server 是一款基于Apache Tomcat 的企业级 Web 应用程序服务器。

虽然 SpringSource 不是第一家围绕 Apache Tomcat 构建产品的公司（WebSphere Community Edition 和 JBoss 都在其 J2EE 应用程序服务器中嵌入了 Tomcat 版本，JBoss Web 2.1.1 的开发者版本也嵌入了 Tomcat），但 tc Server 的独特之处在于它保留了 Tomcat servlet/JSP 编程模型。为 Tomcat 编写的应用程序可以 100% 移植到…

OSGi 联盟已决定通过在公共注册表中列出它们来适应供应商特定的清单头。目的是避免供应商之间以及供应商与 OSGi 自身头文件之间的冲突。

该注册表当前包含 OSGi 自身的头文件、SpringSource dm Server 引入的头文件以及 bnd 工具使用的两个头文件。

简介

这是描述在SpringSource dm Server™中构建和部署 GWT 应用程序的分步方法的三篇博客中的第二篇。第一篇博客介绍了从 GWT 示例应用程序创建简单 WAR 文件的过程。这篇博客将介绍如何将我们在第 1 部分中创建的 WAR 文件转换为“共享库” WAR。这意味着我们将把应用程序的 GWT 依赖项外部化为 OSGi 捆绑包，以便任何数量的 GWT 应用程序都可以共享它。您可以将其视为使用 GWT 远程处理功能扩展我们的 dm Server。

如第 1 部分中所述，我在这篇博客文章中没有使用Spring 框架，而是专注于SpringSource dm Server™和SpringSource Tool Suite来部署“纯”GWT。

另请参阅第 1 部分，了解 GWT StockWatcher 示例和我要使用的软件的背景信息。

快速回顾

在第 1 部分中，我们从头开始构建了 GWT StockWatcher 示例应用程序作为 Eclipse 项目，然后将其代码生成到一个动态 Web 项目中，然后将其部署到 dm Server 中。最后，我们将动态 Web 项目导出到 WAR 文件中，并将其部署在 STS 之外。

此处描述的分步方法将在我们第 1 部分中所做的工作基础上进行构建，而不是重新开始。我们在第 1 部分中现在要更改的唯一一项操作是删除对以下内容的显式依赖项：gwt-servlet.jar库。

步骤 1：将我们的 GWT 依赖项转换为 OSGi 捆绑包

首先，再做一些背景介绍。“共享库”方法的整体概念是在 dm Server 中创建依赖项映射，使用 OSGi 捆绑包之间显式的导入和导出。对于像我们的 StockWatcher 示例这样的小型 WAR，这主要只是一个有趣的学术练习。但是，鉴于许多商业 Web 项目都以包含数十甚至数百个依赖 jar 文件的大型 WAR 文件的形式交付，将这些依赖项分解为可共享的资源不仅在占用空间方面很有意义，而且还使应用程序的打包、版本控制和维护变得更加轻松。

好消息是，创建这些依赖项的大部分工作已经为您完成了。SpringSource 企业捆绑包存储库包含大多数常用库的“捆绑”版本。但是，在撰写本文时，我们的 GWT 依赖项是您必须将其转换为捆绑包的库示例…

在 Glyn 的最近的博客文章中，他介绍了 OSGi“uses”指令。在本篇博客中，我想更深入地探讨 uses 约束冲突的原因，并提供一些在应用程序中诊断 uses 问题的技巧。

对于我将要使用的绝大多数示例，我将使用原始的 Equinox，而不是 dm Server。这样做的原因是 uses 约束并非特定于 dm Server，而是与所有 OSGi 用户相关。在本篇博客的最后，我将演示 dm Server 中内置的一些智能约束失败诊断。

依赖约束不匹配

uses 冲突最常见的原因是依赖约束之一或多个不匹配。例如，考虑以下三个清单

Manifest-Version: 1.0
Bundle-Name: Spring Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: spring
Bundle-Version: 2.5.5
Export-Package: spring.orm.hibernate;version="2.5.5";uses:="eclipselink"
Import-Package: eclipselink;version="[1.0, 2.0)"

Manifest-Version: 1.0
Bundle-Name: EclipseLink 1 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: eclipselink
Bundle-Version: 1
Export-Package: eclipselink;version="1.0.0"

Manifest-Version: 1.0
Bundle-Name: EclipseLink 2 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: eclipselink
Bundle-Version: 2
Export-Package: eclipselink;version="2.0.0"

在这里，您可以看到一个spring 捆绑包和两个eclipselink 捆绑包。显然，这些不是真正的捆绑包。spring 捆绑包对[1.0, 2.0)范围内的eclipselink 包进行了导入。显然，只有eclipselink_1 捆绑包可以满足此约束。现在，考虑来自两个不同应用程序的这些清单

Manifest-Version: 1.0
Bundle-Name: App1 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: app1
Bundle-Version: 1.0.0
Import-Package: spring.orm.hibernate,eclipselink;version="[1.0, 1.0]"

Manifest-Version: 1.0
Bundle-Name: App2 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: app2
Bundle-Version: 1.0.0
Import-Package: spring.orm.hibernate,eclipselink;version="[2.0, 2.0]"

在这里，我们可以看到app1 在 [1.0, 1.0] 范围内导入eclipselink，而app2 在[2.0, 2.0] 范围内导入eclipselink。如果我将这些捆绑包安装到 Equinox 中，然后尝试启动应用程序捆绑包，控制台将显示如下内容

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
2       RESOLVED    spring_2.5.5
3       RESOLVED    eclipselink_1.0.0
4       RESOLVED    eclipselink_2.0.0
5       ACTIVE      app1_1.0.0
6       INSTALLED   app2_1.0.0

在这里，我们可以看到spring 和eclipselink 捆绑包都已解析。app1 捆绑包已启动，但app2 捆绑包无法启动。要找出原因，我们可以使用diag 命令

osgi> diag app2
file:/Users/robharrop/dev/resdiag/uses/app2/bin [6]
  Package uses conflict: Import-Package: spring.orm.hibernate; version="0.0.0"

在这里，我们可以看到app2 捆绑包无法解析，因为其对spring.orm.hibernate 的导入存在包使用冲突。这意味着app2 中对spring.orm.hibernate 的导入无法满足，因为其其他导入之一与可能提供spring.orm.hibernate 的捆绑包上的 uses 约束冲突 - 在这种情况下为spring 捆绑包。

诊断此问题的第一步是找出spring.orm.hibernate 捆绑包的可能提供者。我们从用例中知道，唯一可能的提供者是spring 捆绑包，但是如果您不知道提供者，可以使用 packages 命令找到它们

osgi> packages spring.orm.hibernate
spring.orm.hibernate; version="2.5.5"<file:/Users/robharrop/dev/resdiag/uses/spring/bin [2]>
  file:/Users/robharrop/dev/resdiag/uses/app1/bin [5] imports

这向我们显示spring.orm.hibernate 包由捆绑包2 导出。有了这些信息，我们就可以找出捆绑包2 中spring.orm.hibernate 包的uses 指令中列出了哪些包

osgi> headers 2
Bundle headers:
 Bundle-ManifestVersion = 2
 Bundle-Name = Spring Bundle
 Bundle-SymbolicName = spring
 Bundle-Version = 2.5.5
 Export-Package = spring.orm.hibernate;version="2.5.5";uses:="eclipselink"
 Import-Package = eclipselink;version="[1.0, 2.0)"
 Manifest-Version = 1.0

在这里，我们可以看到 uses 中唯一的包是eclipselink 包，因此它一定是罪魁祸首。实际上，我们可以看到 Spring 捆绑包在[1.0, 2.0) 范围内需要eclipselink，而app2 在[2.0, 2.0] 范围内需要eclipselink - 这两个范围是不相交的，这意味着app2无法连接到与spring 捆绑包相同的eclipselink 版本。

在uses 列表很长的情况下，您可以通过找出其中哪些列出的包具有多个提供者来缩小可能的冲突范围。必须始终存在多个提供者，您才能看到uses 约束冲突。

版本不匹配不是依赖约束不匹配的唯一原因。由于属性以及版本，约束可能不匹配。

安装顺序问题

如果我们重新审视之前的示例，并更改spring bundle 的清单，使其能够接受 eclipselink 包的 2.0 版本，并放宽对 app1 的范围，使其能够接受任何高于 1.0 的版本，我们应该能够解决这个问题。

Manifest-Version: 1.0
Bundle-Name: Spring Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: spring
Bundle-Version: 2.5.5
Export-Package: spring.orm.hibernate;version="2.5.5";uses:="eclipselink"
Import-Package: eclipselink;version="[1.0, 2.0]"

Manifest-Version: 1.0
Bundle-Name: App1 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: app1
Bundle-Version: 1.0.0
Import-Package: spring.orm.hibernate,eclipselink;version="1.0"

安装 bundle 并启动应用程序 bundle 显示此更改产生了很大影响。

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       RESOLVED    eclipselink_2.0.0
4       ACTIVE      app1_1.0.0
5       ACTIVE      app2_1.0.0

现在两个应用程序 bundle 都可以启动了。不幸的是，还有一个更微妙的问题在等待我们。根据安装顺序，这组 bundle 仍然可能无法一起运行。为了说明这一点，让我们将 spring、eclipselink_1 和 app1 作为一笔事务安装，并启动 app1。

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       ACTIVE      app1_1.0.0

现在，让我们安装 eclipselink_2 和 app2。

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       ACTIVE      app1_1.0.0
4       RESOLVED    eclipselink_2.0.0
5       INSTALLED   app2_1.0.0

app2 bundle 无法启动。来自 diag 的输出告诉我们原因。

osgi> diag app2
file:/Users/robharrop/dev/resdiag/uses/app2/bin [5]
  Package uses conflict: Import-Package: spring.orm.hibernate; version="0.0.0"

uses 约束又回来了。运行上一节中确定的诊断步骤在这里没有帮助，因为没有依赖约束不匹配 - 我们知道这一点是因为第一次这些 bundle 完美地解析了。

这里的问题是解析顺序。bundle 分成两个不同的块进行安装和解析。第一个块包括 spring、eclipselink_1 和 app1，第二个块包括 eclipselink_2 和 app2。当第一个块解析时（由于启动了 app1 bundle），spring bundle 会连接到 eclipselink_1 bundle 以导入 eclipselink 包。可以使用控制台确认这一点。

osgi> bundle app1
file:/Users/robharrop/dev/resdiag/uses/app1/bin [3]
  Id=3, Status=ACTIVE      Data Root=/opt/springsource-dm-server-1.0.0.RELEASE/lib/configuration/org.eclipse.osgi/bundles/3/data
  No registered services.
  No services in use.
  No exported packages
  Imported packages
    spring.orm.hibernate; version="2.5.5"<file:/Users/robharrop/dev/resdiag/uses/spring/bin [1]>
    eclipselink; version="1.0.0"<file:/Users/robharrop/dev/resdiag/uses/eclipselink1/bin [2]>
  No fragment bundles
  Named class space
    app1; bundle-version="1.0.0"[provided]
  No required bundles

请注意，导入包部分显示 eclipselink 版本 1.0.0 是从 eclipselink_1 bundle 导入的。当安装第二个块时，app2 bundle 无法解析，因为它需要版本 2.0.0 的 eclipselink，但 spring 已经连接到版本 1.0.0 的 eclipselink。当所有 bundle 作为单个块安装和解析时，OSGi 解析器将尝试满足所有约束，包括确保可以满足 spring.orm.hibernate 上的 uses 约束。

要解决此问题，我们不需要更改 bundle。相反，我们可以将 bundle 重新安装为一个块，或者我们可以针对 spring bundle 触发刷新 - 有效地要求 OSGi 重新运行解析过程。现在 eclipselink_2 bundle 已安装，我们可以预期会有不同的结果。

osgi> refresh spring

osgi> ss

Framework is launched.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       ACTIVE      app1_1.0.0
4       RESOLVED    eclipselink_2.0.0
5       ACTIVE      app2_1.0.0

osgi> bundle spring
file:/Users/robharrop/dev/resdiag/uses/spring/bin [1]
  Id=1, Status=RESOLVED    Data Root=/opt/springsource-dm-server-1.0.0.RELEASE/lib/configuration/org.eclipse.osgi/bundles/1/data
  No registered services.
  No services in use.
  Exported packages
    spring.orm.hibernate; version="2.5.5"[exported]
  Imported packages
    eclipselink; version="2.0.0"<file:/Users/robharrop/dev/resdiag/uses/eclipselink2/bin [4]>
  No fragment bundles
  Named class space
    spring; bundle-version="2.5.5"[provided]
  No required bundles

请注意，刷新 spring 导致 app2 bundle 解析。spring 中 eclipselink 包的连接已更改，以满足 eclipselink_2 bundle 中版本 2.0.0 的导出。

dm Server 中的 Uses 约束

当您在 dm Server 中遇到 uses 约束违规时，我们已经尝试为您执行一些分析步骤，特别是识别可能不匹配的依赖约束。

Could not satisfy constraints for bundle 'app2' at version '1.0.0'.
 Cannot resolve: app2
  Resolver report:
    Bundle: app2_1.0.0 - Uses Conflict: Import-Package: spring.orm.hibernate; version="0.0.0"
      Possible Supplier: spring_2.5.5 - Export-Package: spring.orm.hibernate; version="2.5.5"
        Possible Conflicts: eclipselink

Uses 约束在企业库中很常见，手动诊断故障可能是一场真正的噩梦。特别是，当导出的包在其 uses 子句中列出了 10 个或更多包时，确定可能的冲突可能非常耗时。因此，自动诊断是必须的，我希望始终改进 dm Server 中的诊断代码，以便处理常见错误变得微不足道。

在下一个版本中，我们计划将诊断工具直接构建到我们的 dm Server Eclipse 工具中，以便 dm Server 自动诊断大多数这些问题。

我很高兴地宣布自 SpringSource 收购 G2One 以来，Grails 的第一个版本发布。Grails 1.0.4 包含许多改进，以及对支撑 Grails 的关键库的升级，您可以从 Grails 下载页面 下载。更具体地说，Grails 1.0.4 附带了一周前发布的 最新的 Spring 2.5.6 版本。

除了 这些改进 之外，此版本中还有一些有趣的新功能。第一个是添加了一个功能，该功能更好地支持在 GORM 中映射 Hibernate 用户类型定义。您现在可以映射自定义用户类型……

我很高兴地宣布 SpringSource 已收购 G2One，该公司是 Grails 和 Groovy 背后的公司。

为什么？

我对这笔交易感到兴奋的原因有很多。

Grails 与 Spring 和 SpringSource 技术非常契合。Grails 建立在 Spring 之上。它提供了另一种采用 Spring 的途径，Spring 是企业 Java 事实上的标准组件模型。每个基于 Grails 的应用程序的表面之下都蕴藏着 Spring（以及 Java）的全部强大功能——这是 Grails 可以扩展到企业用途的关键原因，也是 Spring 强大功能和灵活性的证明。

与 Spring 一样，Grails 也是一项简化开发人员生活并提高其生产力的技术。正如我们的新口号“对抗 Java 复杂性的武器”所反映的那样，简化一直是我们作为公司和技术人员的核心工作……

简介

这将是一系列 3 篇博文，描述在 SpringSource dm Server™ 中构建和部署 GWT 应用程序的分步方法。这些博文的重点如下

1. 使用 SpringSource Tool Suite 从头开始构建 GWT StockWatcher 示例应用程序作为 WAR 文件在 dm Server 中部署。
2. 使用 “共享库” 方法部署：如何从 WAR 中删除 GWT 依赖项并在 dm Server 中将其作为 OSGi bundle 部署。
3. 使用 “共享服务” 方法部署：我们将单个 WAR 文件转换为 OSGi 服务，其他应用程序可以共享这些服务并对其进行热交换。

值得注意的是，在前面两篇博文中，我没有在任何地方使用 Spring Framework。Spring 和 GWT 之间的集成本身就是一个主题，我想尽量使每篇博文都尽可能专注。在第三篇博文中，我将展示如何使用 Spring 发布和使用 OSGi 服务，以及如何将其与 GWT 集成。

背景

本博文将采用实用的分步方法来构建此处描述的 GWT StockWatcher 示例 here。Google 教程引导您完成使用 RPC 从头开始构建 GWT 示例所需的步骤。在我们的过程中，我们将参考教程中的页面并讨论各种方法的优缺点。

本博文假设您已安装 SpringSource Tool Suite 1.1.1（我使用的是 Eclipse 3.4 版本）、dm Server 1.0.0 和 GWT 1.5。它还假设您对 Java 编程有很好的了解，并对 Javascript 和 Ajax 有基本的了解。

为了演示中使用的路径的目的，我在以下位置创建了一个新的 Eclipse 工作区/Users/bcorrie/gwt/workspace。我已经包含了您可以在下面下载的压缩项目，其中包含一个GWT_ROOT_INSTALL我已定义的变量。要使用我的项目，当您导入它们时，导航到“首选项”->“Java”->“构建路径”->“类路径变量”并定义您自己的GWT_ROOT_INSTALL…

不，不是 11 月 4 日的奥巴马/麦凯恩对决。您可能已经在 SD Times 中读到，SpringSource 与 SAP、爱立信、诺基亚、飞利浦和 IBM 一道当选为 Java SE/EE 的 JCP 执行委员会成员。我将担任 SpringSource 的代表。

并不是说 JCP 的规模与总统竞选相匹配。但对 SpringSource 来说，这是一个重要的时刻，它反映了 SpringSource 整个团队多年来在企业 Java 中付出的辛勤工作和领导力。更重要的是，我相信我们的当选将有助于我们使 Java 更加强大。

从 第一本书 到……

2008 年 10 月 28 日更新：添加了最新的示例链接和第三个示例的链接

昨晚我在 费城 Spring 用户组 做了“SpringSource dm Server 简介”的演讲。在此演示中，我创建了一个名为 GreenPages 的小型应用程序，演示了 dm Server 的所有主要方面。我向与会者承诺我会将应用程序和幻灯片发布在这里。

在 dm Server GA 版本发布后的几周内，许多人一直在询问开始使用 dm Server 的最佳方法，因此我使用此条目将所有相关信息收集在一起……