摘自 IBM WebSphere 开发者技术期刊。

引言

Spring 和 Hibernate 是两个开放源代码项目，有些客户可能有兴趣使用它们。本文描述如何配置这些框架，以便与 WebSphere Application Server 一起在各种场景中使用。不过，本文不是对某一框架的认可或推荐。IBM 也不直接支持其中任何一个开放源代码项目。IBM 支持有限制地使用这些应用程序框架（如下面所述），就像它支持在 WebSphere Application Server 上运行的任何客户的应用程序一样。本文还描述一些不支持的场景，在 WebSphere Application Server 和堆栈产品中应该避免此场景。

回页首

产品和客户技术支持

一个用户理应关注的问题是那些使用开放源代码的项目所获得的支持，以及使用开放源代码对供应商支持其许可产品的影响。IBM 了解某些客户可能希望将非 IBM 的框架和 IBM WebSphere Application Server 结合使用，并且在为客户提供一些信息，以促进他们为 IBM WebSphere Application Server 创建最可靠的操作环境。IBM 考虑了客户安装的开放源代码和应用程序框架，它们或者绑定为应用程序的一部分，或者作为共享库成为应用程序代码的一部分。在使用开放源代码项目时通过谨慎地利用此信息，客户可以满怀信心地使用 IBM 产品，并继续访问 IBM 产品和技术支持。如果在将这些框架与 WebSphere 产品结合使用时遇到问题，IBM 将尽力确保 WebSphere 产品不出现问题。

如果客户认真研究了本文中的建议，并记住避免和理解以下几个关键点，则预期可以安全地在 IBM 产品上使用 Spring 和 Hibernate 之类的框架：

• 客户必须确保按 WebSphere Application Server 允许的方式使用这些框架。具体说来，这意味着客户在使用内部产品接口时，不应使用框架——遗憾的是，许多开放源代码框架在未经认真配置的情况下就这样使用了。客户应避免在 WebSphere 上明确记录应避免的场景。

• 对于开放源代码框架，客户应该确保理解并能够访问他们与 WebSphere Application Server 一起使用的框架的匹配源代码和二进制。

• 建议客户从开放源代码社区或使用开放源代码社区的合作伙伴那里获取框架的补救性服务。

有关 IBM 支持和策略的详细信息，请参考 IBM Support Handbook 和 WebSphere Application Server Support Statement。

尽管在开放源代码环境中使用 WebSphere Application Servers 时按照本文的建议做法有助于增强您的体验，但本文并没有列出开放源代码组件影响 WebSphere Application Server 操作或其他组件操作的所有情况。使用开放源代码的用户务必检查所有组件的规范，以避免出现许可、支持和技术问题。

在本文的剩余部分中，当使用术语“支持”或“受支持”时，描述的用法仅限于使用 IBM 有文档记录的功能。作者已尽了最大努力来提供有关如何配置和使用这些框架的建议，以确保其用法与记录的产品行为一致。

回页首

Hibernate

Hibernate 是传统的 Java™ 对象 (POJO) 的开放源代码持久性框架，它通过 XML 配置文件提供 POJO 到关系数据库表的与对象相关的映射。Hibernate 框架是应用程序调用的、用于数据持久性的数据访问抽象层。此外，Hibernate 还提供了从 Java 类到数据库表（以及从 Java 数据类型到 SQL 数据类型）的映射以及数据查询和检索功能。Hibernate 生成必需的 SQL 调用，还负责结果集处理和对象转换。

Hibernate 由 Gavin King（Hibernate 项目的奠基人）领导的软件开发团队开发，目的是解决 EJB 2.x 实体 EJB 中存在的诸多缺陷。Hibernate 与 JBoss Group 紧密关联，这是由于 JBoss 雇佣了大量的一流 Hibernate 开发人员的结果。最近，在 Java Community Process (JCP) 中的持久性框架的发展中已涉及 Hibernate，并且 Hibernate 的许多概念已合并到 Java Persistence API (JPA) 规范中。最新版本的 Hibernate 将发展为符合 JPA 规范。JPA 似乎将成为主要的 Java 持久性 API。具体说来，JPA 是 Java EE 5 必要部分。（有关如何使用 Hibernate 的 developerWorks 文章，请参见参考资料。）

尽管下文的描述中支持在 WebSphere Application Server 上使用 Hibernate，但是 IBM 并不直接支持 Hibernate。任何人使用 Hibernate 时都需要按 Hibernate Project Support page 的描述获取对它的支持。客户应该保留与开源项目相关的源数据，以用于问题调试。

使用场景

以下场景描述了有关如何将 Hibernate 与 WebSphere Application Server 和 WebSphere 堆栈产品结合使用的一些可能场景。这些仅是示例场景，不应认为是推荐的场景。前文已提到，客户应该保留与开源项目相关的源数据，以用于问题调试

使用 WebSphere Application Server 数据源

为使 Hibernate 从 WebSphere Application Server 获取数据库连接，必须使用 Java EE（以前称为 J2EE）规范中强制规定的资源引用。这可以确保 WebSphere Application Server 能够为连接池、事务语义和隔离级别提供正确的行为。通过设置 hibernate.connection.datasource 属性（在 Hibernate 配置文件中进行了定义）将 Hibernate 配置为从 WebSphere Application Server 检索数据源，以引用在模块的部署描述符中定义的资源引用（例如 java:comp/env/jdbc/myDSRef）。例如：

<property name="hibernate.connection.datasource">
	java:/comp/env/jdbc/myDSRef
</property>

Web 应用程序的 Java EE 资源引用在 WAR 文件级别定义，这意味着容器中的所有 Servlet 和 Java 类均共享资源引用。在 EJB 模块内部，资源引用在各个 EJB 组件上定义。这意味着，如果许多 EJB 组件都使用相同的 Hibernate 配置，则每个 EJB 必须在每个 EJB 组件上定义相同的引用名称。这会导致复杂的情况，稍后我们将进一步讨论。

配置了数据源之后，确保 Hibernate 正常工作的下一个步骤是正确配置事务支持。

事务策略配置

为了正确地使用事务，Hibernate 需要两个重要部分的配置。第一个部分是 hibernate.transaction.factory_class，它定义事务控制，第二个部分是 hibernate.transaction.manager_lookup_class，它定义注册事务同步的机制，这样，当持久性管理器需要与数据库同步更改时会在事务端得到通知。对于事务控制，同时支持容器管理的配置和 Bean 管理的配置。将 Hibernate 和 WebSphere Application Server 结合使用时，必须在 Hibernate.cfg.xml 中设置以下属性：

• 对于容器管理的事务：

  <property name="hibernate.transaction.factory_class"> org.hibernate.transaction.CMTTransactionFactory </property> <property name="hibernate.transaction.manager_lookup_class"> org.hibernate.transaction.WebSphereExtendedJTATransactionLookup </property>

  
  

• 对于 Bean 管理的事务：

  <property name="hibernate.transaction.factory_class"> org.hibernate.transaction.JTATransactionFactory </property> <property name="hibernate.transaction.manager_lookup_class"> org.hibernate.transaction.WebSphereExtendedJTATransactionLookup </property> <property name="jta.UserTransaction"> java:comp/UserTransaction </property >

  
  

jta.UserTransaction 属性将工厂类配置为从 WebSphere 容器获取 UserTransaction 对象实例的实例。

WebSphere Application Server V6.x 和更高版本在 WebSphere 平台上支持 hibernate.transaction.manager_lookup_class 属性，WebSphere Business Integration Server Foundation V5.1 和更高版本也支持此属性。此属性将 Hibernate 配置为使用在 WebSphere Business Integration Server Foundation V5.1 和 WebSphere Application Server V6.0 中引入的 ExtendedJTATransaction 接口，WebSphere ExtendedJTATransaction 接口建立了一个模式，并通过 JTA 1.1 规范在 Java EE 5 中正式确立。

WebSphere Application Server 环境中 Hibernate 的使用模式

当结合使用 Hibernate 和 WebSphere Application Server 时，Hibernate 的“按请求会话”和“长对话”模式均可使用。客户必须选择适用于其应用程序的模式，不过我们主张使用“按请求会话”模式，因为它可以提供更好的扩展性。

• 多个隔离级别

  可共享的连接通过让多个资源用户能够共享现有的连接，改进了在 WebSphere Application Server 中的性能。不过，如果可共享的连接和多个隔离级别都是必需的，则为每个连接配置定义单独的资源引用和 Hibernate 会话工厂。不能够更改共享连接的隔离级别。因此，也不可能使用 hibernate.connection.isolation 属性在共享连接上设置隔离级别。有关连接共享的策略和约束的详细信息，请参见 在 WebSphere Application Server V5 中共享连接。（尽管本文通常适合于在 WebSphere Application Server V5 上使用的所有共享连接，但是连接共享建议仍适用于在 V6.x 上运行的 Hibernate。）

• Web 应用程序

  可以在 HttpSession 对象中使用和存储 Hibernate 的“长对话”会话；不过，Hibernate 会话持有活动实例，由于可能需要将会话序列化或将其复制到其他集群成员，因此将其存储在 HttpSession 中不是可扩展模式。最好使用 HttpSession 来存储断开连接的对象（只要它们非常小，即 10KB 到 50KB），并且在需要更新时，重新将它们与新的 Hibernate 会话关联。这是因为 HttpSession 最适用于书签，而不适用于缓存。在 Improving HttpSession Performance with Smart Serialization 中讨论了如何使 HttpSession 的内存使用率降至最低。不是将 HttpSession 用作缓存，而是考虑使用 ObjectGrid 或 DistributedObjectCache 之类的 WebSphere 数据缓存技术，这在下一部分进行介绍。

有关高性能、可扩展应用程序的最佳实践，强烈建议您阅读 Performance Analysis for Java Websites 一书。

集成二级缓存

Hibernate 会话表示工作单元的范围。在 Hibernate 会话的生命周期中，Session 接口管理持久性。通常，它通过保持对单一线程有效的一级缓存实例并维护它负责的映射实体类实例的识别或状态做到这一点。在完成工作单元（会话）时释放缓存。还可以将二级缓存配置为在 SessionFactory 的所有会话之间共享（包括在群集之间共享）。请注意，在 Hibernate 中进行缓存会导致一些需要解决的问题。第一，对于数据库的外部更改或跨群集更改，无法确保缓存的一致性（除非使用识别群集的缓存）。第二，其他层（如数据库）可能已经缓存，从而使 Hibernate 缓存的值降至最低。在进行应用程序设计时，必须认真考虑这些问题，但是这些问题超出了本文的讨论范围。

在发布时，没有确定与 WebSphere Application Server 相关的 Hibernate 群集识别缓存的行为，因此，还不能确定是否支持该行为，我们对此不做进一步的讨论。所以，需要分布式缓存的客户应当考虑创建使用属性 hibernate.cache.provider_class 实现 org.hibernate.cache.CacheProvider 的类,这会在 WebSphere 中使用两个分布式缓存实现中的一个。

Hibernate 附带了几个预配置的缓存。在 Hibernate Cache 文档页中可以找到关于这些缓存的信息。对于只读数据，一个内存缓存可能就足够了。不过，当聚集应用程序并需要群集识别缓存时，本地只读缓存是不够的。如果需要分布式缓存，我们建议使用 WebSphere 提供的分布式缓存实现之一。可以将它们用作 Hibernate 的二级缓存：

• DistributedMap / DistributedObjectCache 接口提供支持 WebSphere v6.x 产品系列的分布式缓存。有关详细信息，请参见 Using the DistributedMap and DistributedObjectCache interfaces for the dynamic cache。

• 作为 WebSphere Extended Deployment 产品一部分的 ObjectGrid 提供可扩展的对象缓存支持。有关详细信息，请参见 ObjectGrid。

在 WebSphere Enterprise Service Bus 和 WebSphere Process Server 中使用 Hibernate

WebSphere Process Server 和 WebSphere Enterprise Service Bus (ESB) 将 Service Component Architecture (SCA) 和 Service Data Objects (SDO) 用作 SOA 的装配和编程模式。（请参见参考资料，了解关于 SCA 和 SDO 的更多信息。）SCA 组件不是 Java EE 组件，因此它们没有资源引用，但是改为依靠服务和适配器来连接系统。在构建 Java SCA 组件时，不能使用资源引用；因此，SCA 组件不能直接使用 Hibernate。

在这种情况下，应将 Hibernate 持久性隐藏在某种 Facade 后面。有两个备选方案：

• 创建本地 EJB 会话 Facade 以包装 Hibernate 持久性。会话 Facade 提供适配器逻辑，以便将 Hibernate 实体 POJO 映射到服务数据对象并返回。然后集成开发人员可以使用 EJB 导入调用会话 Facade，并以紧密耦合方式使用对应的服务质量 (QoS) 调用它。

• 创建 EJB Web 服务会话 Facade 以包装 Hibernate 持久性。然后集成开发人员可以使用 Web 服务导入调用持久性的 Web 服务。这不需要构建 POJO 到 SDO 的转换程序，由于目前 SCA 对数据类型只使用 SDO。图 1 说明了使用两个模式的业务流程，但该流程的详细信息不在本文的讨论范围之内。

WebSphere Application Server V6.1 上的 Hibernate JPA API

Hibernate 的 JPA 支持提供 JPA 标准持久性，并且是专有 Hibernate API 的较好备选方案。Hibernate 的 JPA 实现需要基于 Java EE 5 的运行时，因此，它仅在 WebSphere Application Server V6.1 或更高版本上运行。在发布时，Hibernate 的 JPA 支持不能在 WebSphere z/OS 和 iSeries 平台上运行。Hibernate 文档描述了如何使用 Hibernate 的 JPA 实现包装和部署应用程序。

避免的场景

以下各部分将描述不支持的配置和用例。这仅表示当前已确定的不支持的场景。其他不支持的场景将在以后确定。

不支持的事务配置

Hibernate 文档描述了用于在 WebSphere Application Server 版本 4 和 5 产品上运行的事务策略配置，但是这些配置使用内部 WebSphere 接口，在那些早期版本上不受支持。在上面的事务策略配置部分中描述了 Hibernate 唯一支持的事务配置。正如前面所述，这意味着仅在 WebSphere Application Server V6.x 之后（包括 V6.x）的版本和 WebSphere Business Integration Server Foundation V5.1 上支持使用 Hibernate。

不可交互操作的／不可移植的功能

JPA 规范中的 3.2.4.2 部分描述了可能导致互操作性和潜在的可移植性问题的情况。这与结合使用延迟加载（即 @Basic(fetch=LAZY)）和分离对象有关。将分离对象合并回会话时，JPA 将检查该对象，并使用任何更改值来更新数据存储。不过，数据对象是简单的 POJO。在分离时，如果部分 POJO 状态没有加载，则在合并回去时可能显示为已更改。要使它正常工作，供应商必须实现特定于其运行时的序列化技术。这不是互操作的，语义也不能移植。

回页首

Spring

通常将 Spring 描述为轻量级容器环境，但是将其描述为用于简化开发的框架可能更适当。其主要概念是使用依赖项注入 (DI) 和面向方面的编程 (AOP) 来简化和平稳地进行从开发到测试再到生产的转换。

Spring 框架是一个流行的开放源代码框架，它由 Interface21, Inc. 根据 Rod Johnson 发表的关于依赖项注入 (DI) 的设计模型开发。Spring 可以在独立应用程序或应用服务器中使用。由于 Spring 提供的一些服务通常由应用服务器运行时提供，所以需要认真设计 Spring 与应用服务器的结合使用，以避免在 Spring 实现和应用服务器提供的实现之间发生冲突。

本部分其余内容将描述使可能发生的实现冲突或矛盾点降至最低的用例，还将描述应避免的其他矛盾点（如果可能）。

尽管下文的描述中支持在 WebSphere Application Server 上有限使用 Spring，但是 IBM 并不直接支持 Spring。任何人使用 Spring 时都需要按 Spring Product Support page 的描述获取对它的支持。客户应该保留用于帮助调试问题的与开放源代码项目相关的源。

使用场景

以下部分将描述 Spring 在 WebSphere Application Server 上的一些使用场景。不过，应由客户负责确定这些场景是否适合他们的具体情况。IBM 不支持、也不建议使用 Spring。本文仅演示在 WebSphere Application Server 上使用 Spring 的一组场景，并演示必须如何自定义 Spring 才能与 WebSphere Application Server 一起运行。

简单的 Bean 逻辑容器

使用 Spring 的最常用的场景之一是使用简单的 Java Bean 类配置并驱动业务逻辑。本文稍后描述的避免了问题的 Spring 应用程序在 WebSphere Application Server 中运行时不应该有任何问题。Spring documentation page 应提供了使用 Spring Bean 构建应用程序的足够信息。此处不存在任何特定于 WebSphere 的内容。

在 WebSphere 中使用 Spring DAO 框架

下面是关于在 WebSphere Application Serveruse 上使用 Spring DAO 功能的三个示例：

• 基本型 DAO 用法

  WebSphere Application Server 管理在应用服务器执行环境中使用的资源。需要访问 JDBC 数据源之类资源的 Spring 应用程序应该利用 WebSphere 管理的资源。为此，需要执行以下若干步骤。

  1. 在开发过程中，应该使用资源引用配置 WAR 模块。例如：

     <resource-ref> <res-ref-name>jdbc/springdb</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Shareable</res-sharing-scope> </resource-ref>

     
     

  2. 对于 EJB JAR 文件，应该在需要访问数据源的每个 EJB 中声明同一资源引用。

  3. 然后使用与以下类似的内容在 Spring 配置文件中声明数据源 Bean：

     <bean id="WASDataSource" class="org.springframework.jndi.JndiObjectFactoryBean"> <property name="jndiName" value="java:comp/env/jdbc/springdb"/> <property name="lookupOnStartup" value="false"/> <property name="cache" value="true"/> <property name="proxyInterface" value="javax.sql.DataSource"/> </bean>

     
     

     这将配置 Bean，以便从模块的配置引用查找数据源。注意，jndiName 属性值匹配与资源引用中声明的资源引用名称连接的模式 java:comp/env/。

  4. 然后，Spring 应用程序可以在适当情况下使用数据源 Bean。

  5. 将应用程序部署到 WebSphere Application Server 时，必须配置资源提供程序和资源数据源，以便由 Spring 应用程序资源引用使用。在部署过程中，在模块的部署描述符中声明的资源引用将绑定到应用服务器的配置数据源。

• 事务型 DAO 用法

  在 Spring 中，有许多方法可以驱动事务控制下的资源更新。这包括编程形式和声明形式。声明形式有注释形式和非注释形式。在使用 Spring 事务支持时，获得权限的重要方法是适当地配置 Spring 对底层事务管理器的使用。在 WebSphere Application Server 中，Spring 使用的事务管理器的唯一支持形式如下：

  <bean d="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager"> <property name="autodetectTransactionManager" value="false"/> </bean>

  
  

  可以将此事务管理器 Bean 提供给 JdbcTemplate 类，或通过事务策略的声明形式利用。有关为什么这是唯一形式的详细信息，请参见避免的场景部分。

• 休眠型 DAO 用法

  Spring 记录将 Hibernate 和 Spring 一起使用的基本设置。在 WebSphere Application Server 环境中使用 Hibernate 和 Spring 时，有必要将上述对二者的配置要求合并在一起。正如前面所述，在 Spring 和 Hibernate 中使用 JNDI 访问事务管理的资源和适当配置是必要的。

Spring Web MVC

Spring 的 Web MVC 框架在某一时间内一直是其他框架的备选框架。由 WebSphere Application Server 提交、使用和支持的 Web MVC 框架包括 JSF 和 Struts。Spring 参考手册描述了如何将 Spring 与这些 Web 框架集成。尽管 WebSphere Application Server 支持上面的任何用法，但 IBM 仅为 WebSphere Application Server 附带的框架提供缺陷支持。

计划和线程池

如果需要异步运行代码，那么应该使用 WorkManagerTaskExecutor。在 Spring 中，这是唯一使用由 WebSphere Application Server 托管的线程池的 TaskExecutor 实现。其他 TaskExecutor 实现可以启动非托管线程。有关非托管线程的详细信息，请参见避免的场景。

在 WebSphere Application Server 管理控制台中，通过导航到 Resources => Asynchronous beans => Work managers 可以对 WorkManager 进行设置。然后可以在 Spring 配置文件中使用资源的 JNDI 名称来定义 WorkManagerTaskExecutor。

Spring Portlet

Spring Portlet 可以在 WebSphere Portal V6.0 和 WebSphere Application Server V6.1 Portlet 容器中运行。有关 Spring Portlet 的示例集，请参见 Spring Portlet MVC。在 WebSphere Application Server V6.1 Portlet 容器中运行 Portlet 需要创建其他 Web 应用程序才能定义 Portlet 的布局和聚合。从 WebSphere Application Server 信息中心可以获得关于如何使用 Portlet 聚合器标记库的信息，在文章 探索 WebSphere Application Server V6.1 Portlet 容器: 第 1 部分：Portlet 容器介绍 中的其他补充信息中也可找到。

通常结合使用 JSF 和 Portlet 进行呈现。关于如何将 Spring、Hibernate、JSF 和 WebSphere Portal 组合起来运行的信息可以通过文章 Configuring Hibernate, Spring, Portlets, and OpenInSessionViewFilter with IBM WebSphere Portal Server 了解。

避免的场景

已经知道以下场景在 WebSphere Application Server 环境中会出现问题，应该避免它。列出这些场景的原因有许多，不过，最常见的原因是 Spring 使用了内部 WebSphere 接口。这些内部接口的使用破坏了 WebSphere Application Server 保证应用程序环境的完整性和管理应用程序资源的能力。应该避免使用任何依赖于内部 WebSphere 接口的 Spring 功能。

REQUIRES_NEW 和 NOT_SUPPORTED 事务策略

WebSphere Application Server 为维护数据完整性提供了可靠的环境。它提供此环境的方法之一是始终确保应用程序逻辑在事务范围内执行。在容器将要执行业务逻辑时，它会检查事务状态。如果全局事务不是动态的，则容器会创建并管理新的 local transaction containment (LTC) 范围。容器将在业务逻辑结束时完成 LTC，并在任何应用程序启动的全局事务过程中将它挂起。这可以确保在业务逻辑执行结束时总是正确地清除资源。

Spring 为管理事务提供了机制。不过，它支持的事务策略超出了通常可以在应用程序级别处理的策略集的范围。具体说来，它为 REQUIRES_NEW 和 NOT_SUPPORTED 的 EJB 容器管理的语义提供它自已的等效支持。这两个容器管理的策略都需要挂起和恢复事务的功能，但是为使用 EJB 容器而保留了此功能（不适当的使用会导致数据完整性问题）。为提供此行为，Spring 使用了内部 WebSphere 接口，但不知道它对容器的影响。使用内部接口挂起和恢复事务将破坏 Web 和 EJB 容器管理资源和 LTC 的功能，并可能使容器处于未知状态，从而可能导致数据损坏。

以下两个步骤可以避免此场景：

• 不使用需要挂起和恢复语义的 Spring 事务策略。
• 不配置 Spring JtaTransactionManager 使其支持挂起和恢复语义。

第一是应用程序设计时间限制。如果您构建应用程序，请不要在语义中设计需要使用 Spring 来挂起和恢复事务。如果需要挂起和恢复语义，请改为使用无状态会话 EJB。

第二是部署时间配置约束。如果在 WebSphere Application Server 中部署基于 Spring 的应用程序，则该应用程序在尝试使用 Spring 的挂起和恢复语义时将会失败。以这种方式失败比随机数据损坏错误要好得多。下面是必须在 WebSphere Application Server 中配置 Spring JtaTransactionManager 的正确方法：

<bean id="transactionManager"
class="org.springframework.transaction.jta.JtaTransactionManager">
	<property name="autodetectTransactionManager" 
		value="false"/>
</bean>

这将把 transactionManager Bean 配置为使用 UserTransaction API 来控制事务的开始、提交和回滚。这使得可以不使用挂起和恢复语义来支持事务控制。

上面所述的 Spring JtaTransactionManager 用法不支持与现有事务同步的 Spring 注册功能。要做到这一点，需要使用 WebSphereTransactionManagerFactoryBean。使用 WebSphereTransactionManagerFactoryBean 的客户或调用内部事务管理器接口的任何其他类将不受支持。

JDBC 本机连接

当各种 JDBC 操作需要与本机 JDBC 资源交互时，Spring 可提供访问本机连接的机制。当在 JdbcTemplate 类上设置了 NativeJdbcExtractor 类时，JdbcTemplate 类才可以利用此功能。设置 NativeJdbcExtractor 类后，当与 WebSphere Application Server 一起使用时，Spring 总是向下找到本机 JDBC 连接。这将忽略以下 WebSphere QoS 功能和优点：

• 连接处理跟踪和再关联
• 连接共享
• 事务状态
• 池管理
• 最后的代理事务参与。

这带来的另一个问题是 WebSphereNativeJdbcExtractor 类将依赖于内部 WebSphere 适配器类。这些内部类可能因 WebSphere Application Server 的版本而异，并且以后可能更改，从而中断依赖于此功能的应用程序。

在 WebSphere Application Server 上不支持使用 NativeJdbcExtractor 类实现（例如 WebSphereNativeJdbcExtractor），客户应避免需要它的场景。备选方案是使用 WebSphere Application Server WSCallHelper 类来访问非标准供应商的数据源扩展。

类加载器的缺点

Spring 和 WebSphere Application Server 都使用多个开放源代码项目，遗憾的是，它们共有的项目版本并不总是匹配。应该将 Spring 依赖项包装为应用程序的一部分，并且应该按照下面的描述设置服务器以避免冲突。否则，类加载器可能无法为运行时或应用程序加载适当的版本。通常，这将导致在日志中出现有关类的版本不匹配、ClassCastExceptions 或 java.lang.VerifyErrors 等异常。

其中一个示例是使用 Jakarta Commons Logging。配置供应用程序使用的 Jakarta Commons Logging (JCL)，或者使用不是由应用服务器提供的其他版本的 JCL（例如，使用应用程序代码嵌入的 JCL）需要在 WebSphere Application Server 上进行特定的配置。有关如何配置部署的应用程序，以使用内嵌版本的常用技术的策略，请参见 Integrating Jakarta Commons Logging。请关注支持网站，了解是否提供了如何在 WebSphere Application Server V6.x 产品上配置内嵌 JCL 的更新。这仅仅是冲突的一个示例。其他示例可能包括应用程序使用的 JDOM 或特定版本的 JavaMail。不支持将 WebSphere Application Server 的 JAR 文件替换为这些或具有更高版本或不同版本的其他包。

在 WebSphere Application Server 上困扰 Spring 用户的另一个类加载器问题是 Spring 加载资源的方法。资源可以包括消息绑定之类的内容，通过类加载器层次结构和在层次结构中查找资源的各种策略，能够在非目标位置找到使用公共名称的资源。可以使用 WebSphere Application Server 类加载器查看器来帮助解决此问题。合并资源和包括其他版本的公共库可能需要应用程序将资源重命名为唯一的名称。

非托管线程

某些 Spring 场景可能导致创建非托管的线程。非托管线程对 WebSphere Application Server 是未知的，并且不能访问 Java EE 上下文信息。此外，它们可以在 WebSphere Application Server 不知道的情况下利用资源，存在管理员不能控制其数量和资源使用情况的问题，在发生故障时，它们还阻止应用服务器正常关机或恢复资源。应用程序应该避免导致启动非托管线程的任何场景：

• registerShutdownHook

  第一种场景是在使用 Spring AbstractApplicationContext 或它的一个子类时。registerShutdownHook 是一个公共方法，它可以创建线程并将其注册到 Java 虚拟机，以便在关机时运行以关闭 ApplicationContext。应用程序可以避免这一点，方法是利用从 WebSphere 容器接收的常规生命周期通知来显式调用 ApplicationContext 上的关闭。

• 入站 JMS 消息

  Spring JMS MessageListenerContainer 类利用启动非托管线程（例如 SimpleAsyncTaskExecutor）的类来侦听传入的 JMS 消息。Spring JMS 容器不仅可以启动非托管线程，而且还可以使用无法由 Java EE 环境中的应用程序调用的 JMS API。（有关详细信息，请参见 Java EE 规范 J2EE.6.6 部分。）

  可以使用 Spring 远程处理 API 生成 JMS 消息，但是客户应该使用消息驱动的 Bean 处理传入的消息，避免使用 Spring JMS MessageListenerContainer。这可以使用容器适当地控制和恢复资源和事务。

• JMX 服务器

  应用程序应避免使用 Spring JMX ConnectorServerFactoryBean，它是启动非托管线程的另一个类。WebSphere Application Server 已经向 JMX 服务器提供了多个受支持的连接器协议。应用程序可以向 WebSphere Application Server 的 JMX 服务器注册 MBean，并对它们进行远程访问。

• 非集成的计划包

  Spring 提供或集成了大量的计划包。只有与 WebSphere Application Server 托管的线程一起使用的 Spring 计划包是 CommonJ WorkManager 计划包。其他包（如 quartz 和 JDK Timer）会启动非托管线程，应该避免使用。

• WeakReferenceMonitor

  Spring 为简化开发 EJB 组件提供了方便的类。请注意，这些方便的类会生成 WeakReferenceMonitor 用来执行清除操作的非托管线程。

回页首

结束语

如果经过充分考虑避免了问题场景，则可以在 WebSphere 平台上以完全支持的方式使用 Hibernate 和 Spring。尤其是，客户必须确保他们使用这些框架不涉及使用内部 WebSphere 接口。获得 IBM 的 WebSphere Application Server 支持的用户如果在将 WebSphere Application Server 和 Spring 或 Hibernate 一起使用时遇到问题，可以获得 IBM 的帮助来诊断问题，除非问题被确认为使用了不支持的场景，或不是 WebSphere Application Server 的问题。客户应该按照相应项目网络上的说明自行从其他公司获得对 Hibernate 和 Spring 框架的支持。