在Spring环境中建立JPA Spring JPA 提供了三种方法创建JPA EntityManagerFactory：

12.6.1.1. LocalEntityManagerFactoryBean

LocalEntityManagerFactoryBean负责创建一个适合于仅使用JPA进行数据访问的环境的 EntityManager。 Factory bean将使用JPA PersistenceProvider 类的自动检测机制（根据JPA的 Java SE启动），而在绝大多数情况下，只需要指定persistence unit名称：

这种JPA部署方式最为简单，但却最受限制。例如，不能连接到现有的JDBCDataSource， 并且不支持全局事务。甚至，持久化类的织入（字节码转换）也是特定于提供者的，经常需要在启动时指定一个特定的JVM代理。 总之，这种方法实际上只适用于独立的应用程序和测试环境（这正是JPA规范设计它的原因）。

仅在简单部署环境中只使用这种方式，比如独立的应用程序和集成测试。

12.6.1.2. 从JNDI中获取 EntityManagerFactory

从JNDI获取 EntityManagerFactory （例如在Java EE 5环境中），仅通过修改XML配置即可实现：

在标准的Java EE 5启动过程中，Java EE服务器自动检测持久化单元（例如应用程序文件包中的META-INF/persistence.xml） ，以及Java EE部署描述符中定义给那些持久化单元命名上下文位置的环境的persistence-unit-ref项（例如web.xml）。

在这种情况下，整个持久化单元部署，包括持久化类的织入（字码码转换）都取决于Java EE服务器。 JDBC DataSource 通过在META-INF/persistence.xml 文件中的JNDI位置进行定义；EntityManager事务与服务器的JTA子系统整合。Spring仅仅用获得的EntityManagerFactory, 通过依赖注入将它传递给应用程序对象，并为它管理事务（一般通过JtaTransactionManager）。

注意，如果在同一个应用程序中使用了多个持久化单元，JNDI获取的这种持久化单元的bean名称 应该与应用程序用来引用它们的持久化单元名称相符（例如@PersistenceUnit和 @PersistenceContext注解）。

在部署到Java EE 5服务器时使用该方法。关于如何将自定义JPA提供者部署到服务器，以及允许使用服务器提供的缺省提供者之外的JPA提供者，请查看服务器文档的相关说明。

12.6.1.3. LocalContainerEntityManagerFactoryBean

LocalContainerEntityManagerFactoryBean 提供了对JPA EntityManagerFactory 的全面控制，非常适合那种需要细粒度定制的环境。LocalContainerEntityManagerFactoryBean 将基于 persistence.xml 文件创建 PersistenceUnitInfo类，并提供 dataSourceLookup 策略和 loadTimeWeaver。 因此它可以在JNDI之外的用户定义的数据源之上工作，并控制织入流程。

这是最为强大的JPA配置方式，允许在应用程序中灵活进行本地配置。它支持连接现有JDBC DataSource ， 支持本地事务和全局事务等等。然而，它也将需求强加到了运行时环境中，例如，如果持久化提供者需要字节码转换，则必须有织入ClassLoader的能力。

注意，这个选项可能与Java EE 5服务器内建的JPA功能相冲突。因此，当运行在完全Java EE 5环境中时， 要考虑从JNDI获取EntityManagerFactory。另一种可以替代的方法是，在LocalContainerEntityManagerFactoryBean定义中通过“persistenceXmlLocation”指定相关位置， 例如“META-INF/my-persistence.xml”，并且只将包含该名称的描述符放在应用程序包文件中。因为Java EE 5服务器将只 查找默认的META-INF/persistence.xml文件，它会忽略这种定制的持久化单元，因而避免与前面Spring 驱动的JPA配置冲突。（例如，适用于Rdsin 3.1）。

在基于Spring的应用程序环境中使用该方式可获得全部JPA功能。这包括web容器，如Tomcat， 以及独立的应用程序和包含复杂持久化需求的集成测试。

何时需要加载时织入？

并非所有的JPA提供者都需要JVM代理(Hibernate就是一个例子)。 如果你的提供者不需要代理(agent)或者你有其他选择(例如通过自定义编译器或者ant任务在构建时进行增强)，那么就不应该使用加载时织入。

LoadTimeWeaver 接口由Spring提供，允许JPA ClassTransformer 实例 能够根据环境（web容器/应用服务器）以特定的方式插入。 通过Java 5 代理挂钩 ClassTransformers经常是无效的 —— 代理通常在 整个虚拟机 环境下工作，并且监控 每一个 被加载的类 —— 这在生产环境下一般是不提倡的。

Spring提供了大量用于不同环境的 LoadTimeWeaver 实现类， 允许 ClassTransformer 实例能够仅用于每个classloader ，而不是每个虚拟机。

接下来的一节将讨论在Tomcat以及使用Spring的VM代理情况下的典型JPA织入配置。关于设置常用加载时织入的详细内容， 请参见AOP一章中的第 6.8.4.5 节 “Spring配置”一节，它涵盖了Tomcat、VM代理以及WebLogic、OC4J、GlassFish和Resin。

12.6.1.3.1. Tomcat（5.0以上）加载时的织入配置

Apache Tomcat 缺省的ClassLoader（类装载器）并不支持类的切换， 但是它允许使用用户自定义的类装载器。Spring提供了 TomcatInstrumentableClassLoader 类 （在org.springframework.instrument.classloading.tomcat包中），这个类继承自Tomcat的类装载器 （WebappClassLoader）并且允许JPA ClassTransformer 的实例来“增强”所有由它加载的类。 简单说，JPA转化器（JPA transformer）仅仅在（使用TomcatInstrumentableClassLoader 的）特定web应用程序中才能被使用。

为使用用户自定义的类装载器：

1. 将 spring-tomcat-weaver.jar 复制到 $CATALINA_HOME/server/lib 下 （其中$CATALINA_HOME 表示Tomcat的安装路径）。

2. 通过修改web application context使Tomcat使用用户自定义的类装载器（而不是默认的类装载器）：

   Tomcat 5.0.x 和 5.5.x 系列支持多个上下文路径（context locations）： 服务器配置文件($CATALINA_HOME/conf/server.xml)， 默认的上下文配置（$CATALINA_HOME/conf/context.xml）会影响所有被部署的web应用程序、 单独部署在Server端的web应用程序的配置（$CATALINA_HOME/conf/[enginename]/[hostname]/my-webapp-context.xml） 或者与web应用程序一起（your-webapp.war/META-INF/context.xml）。从效率的角度说， 我们推荐在web-app的内部配置的方式，因为仅仅使用JPA的应用程序会使用用户自定义的类装载器。 更多具体有关可用的上下文路径的内容请参见Tomcat 5.x的文档。

   注意，5.5.20之前的版本有一个XML配置解析的bug，造成 server.xml 中无法使用Loader标签，无论是否指定了classloader，也不管这个classloader是官方的还是自定义的。

   　　　　　　　　

   如果你正在使用的是Tomcat 5.5.20以上的版本，就可以将useSystemClassLoaderAsParent设置成 　　　　　　　　false来解决这个问题：

1. 将spring-tomcat-weaver.jar复制到$CATALINA_HOME/lib (where $CATALINA_HOME表示Tomcat安装根目录的位置）。

2. 通过编辑web应用程序上下文文件，使Tomcat使用自定义的ClassLoader（而不是默认的ClassLoader）：

   Tomcat 6.0.x (类似于5.0.x/5.5.x)系列支持几种上下文路径：（context locations）： 服务器配置文件($CATALINA_HOME/conf/server.xml)， 默认的上下文配置（$CATALINA_HOME/conf/context.xml）会影响所有被部署的web应用程序、 单独部署在Server端的web应用程序的配置（$CATALINA_HOME/conf/[enginename]/[hostname]/my-webapp-context.xml） 或者与web应用程序一起（your-webapp.war/META-INF/context.xml）。从效率的角度说， 我们推荐在web-app的内部配置的方式，因为仅仅使用JPA的应用程序会使用用户自定义的类装载器。 更多具体有关可用的上下文路径的内容请参见Tomcat 5.x documentation。

• Tomcat 5.0.x/5.5.x

• Tomcat 6.0.x

所有Tomcat版本所需的最后一步，是在配置LocalContainerEntityManagerFactoryBean的时，使用 相应的LoadTimeWeaver：

利用这种方法，依赖工具的JPA应用程序无需代理就可以在Tomcat上运行。这在宿主应用程序依赖不同的JPA实现时尤为重要， 因为JPA转化器只适用于ClassLoader级别，它们之间是彼此隔离的。

注意

如果Tomcat使用TopLink作为JPA提供者，请将核心的toplink jar包放在$CATALINA_HOME/shared/lib文件夹中，而不再放到war中。

12.6.1.3.2. 使用VM代理的全局加载时织入

对于需要类工具，同时现有的LoadTimeWeaver实现不提供这种支持的环境，JDK代理是唯一的解决方案。对于这种情况，Spring提供了 需要特定于Spring（但非常常用）的VM代理（spring-agent.jar）的InstrumentationLoadTimeWeaver：

请注意在启动虚拟机时，同时启动Spring代理，方法是提供下列JVM选项：

-javaagent:/path/to/spring-agent.jar

12.6.1.3.3. 上下文范围内的加载时织入配置

自Spring 2.5，可以使用context:load-time-weaver元素来配置 上下文范围的LoadTimeWeaver了。这种“全局”织入器由所有JPA LocalContainerEntityManagerFactoryBeans自动拣选。

这是配置加载时织入器的推荐方法，提供平台（ebLogic, OC4J, GlassFish, Tomcat, Resin, VM agent）的自动检测，以及织入器到所有织入器知道的bean的自动传播。

    ...

关于如何建立常用加载时织入的详细内容，请参见第 6.8.4.5 节 “Spring配置”一节，它涵盖了 Tomcat、VM代理，以及WebLogic, OC4J, GlassFish和Resin。

12.6.1.4. 处理多持久化单元

对于那些依靠多个持久化单元位置(例如存放在classpath中的多个jar中)的应用程序， Spring提供了作为中央仓库的PersistenceUnitManager， 避免了持久化单元查找过程(的潜在开销)。缺省实现允许指定多个位置 (默认情况下classpath会搜索META-INF/persistence.xml文件)，它们会被解析然后通过持久化单元名称被获取：

  
    
     org/springframework/orm/jpa/domain/persistence-multi.xml
     classpath:/my/package/**/custom-persistence.xml
     classpath*:META-INF/persistence.xml
    
  
  
   
  
  
  



  

要注意的是，缺省实现允许在将持久化单元信息传入JPA provider之前用 PersistenceUnitPostProcessor(它允许选择持久化单元)修改它们， 传入的过程可以是通过属性声明式地传入(影响其中所有的单元)或编程式地传入。 如果没有指定persistenceUnitManager，LocalContainerEntityManagerFactoryBean 会创建一个并在内部使用它。

12.6.2. JpaTemplate 和 JpaDaoSupport

每个基于JPA的DAO都将通过依赖注入接收一个 EntityManagerFactory 实例。 这样的DAO可以通过指定的 EntityManagerFactory 来操作原生JPA的API进行数据访问， 也可以直接使用Spring的 JpaTemplate：

public class JpaProductDao implements ProductDao {
  
    private JpaTemplate jpaTemplate;

    public void setEntityManagerFactory(EntityManagerFactory emf) {
        this.jpaTemplate = new JpaTemplate(emf);
    }

    public Collection loadProductsByCategory(final String category) throws DataAccessException {
        return (Collection) this.jpaTemplate.execute(new JpaCallback() {
            public Object doInJpa(EntityManager em) throws PersistenceException {
                Query query = em.createQuery("from Product as p where p.category = :category");
                query.setParameter("category", category);
                List result = query.getResultList(); 
                // do some further processing with the result list
                return result;
            }
        });
    }
}

JpaCallback 实现允许任意类型的JPA数据访问。 JpaTemplate 将确保 EntityManager 正确地打开和关闭，并且能够自动地参与到事务中去。 除此之外，JpaTemplate 能够恰当地处理异常，确保资源的及时清理以及必要时的事务回滚。 Template实例不仅是线程安全的，而且它是可重用的，因而它能够作为实例变量被一个类持有。 注意， JpaTemplate 提供了简单的诸如find、load、merge等操作的快捷函数来替代默认的回调实现。

不仅如此，Spring还提供了一个方便的 JpaDaoSupport 基类，提供了 get/setEntityManagerFactory 方法以及 getJpaTemplate() 方法供子类调用：

public class ProductDaoImpl extends JpaDaoSupport implements ProductDao {
  
    public Collection loadProductsByCategory(String category) throws DataAccessException {
        Map params = new HashMap();
        params.put("category", category);
        return getJpaTemplate().findByNamedParams("from Product as p where p.category = :category", params);
    }
}

除了直接使用Spring的 JpaTemplate之外，也可以使用原生JPA的API来实现基于Spring的DAO， 此时你需要自行明确地处理EntityManager。正如在相应的Hibernate章节描述的一样，这种做法的主要优 点在于你的数据访问代码可以在整个过程中抛出checked exceptions。JpaDaoSupport 为这种情况提 供了多种函数支持，包括获取和释放一个具备事务管理功能的 EntityManager 和相关的异常转化。

JpaTemplate主要以JdoTemplate和HibernateTemplate的同胞而存在，为使用它的人们提供相同的风格。 对于新启动的项目，要考虑采用原生的JPA风格编写数据访问对象的代码，基于通过JPA@PersistenceContext注解 获取的一个“共享EntityManager”引用（利用Spring的PersistenceAnnotationBeanPostProcessor；详情如下。）

12.6.3. 基于原生的JPA实现DAO

注意

虽然EntityManagerFactory实例是线程安全的， 但EntityManager实例确实不是这样。被注入的JPA EntityManager的行为和从应用服务器JNDI环境中获取的没有区别， 和JPA规范定义的一样。如果存在一个被注入的JPA EntityManager， 它会代理对当前事务化的EntityManager的所有调用； 否则每个操作都会创建一个EntityManager，确保线程安全。

你完全可以使用原生的JPA的API进行编程，而无需对Spring产生任何依赖，这可以通过一个被注入的 EntityManagerFactory 或 EntityManager 来完成。 注意，如果 PersistenceAnnotationBeanPostProcessor 被启用，Spring就能够识别字段或者方法级别的 @PersistenceUnit 和 @PersistenceContext 注解。相应的DAO实现看起来像这样：

public class ProductDaoImpl implements ProductDao {

    private EntityManagerFactory emf;

    @PersistenceUnit
    public void setEntityManagerFactory(EntityManagerFactory emf) {
        this.emf = emf;
    }

    public Collection loadProductsByCategory(String category) {
        EntityManager em = this.emf.createEntityManager();
        try {
             Query query = em.createQuery("from Product as p where p.category = ?1");
             query.setParameter(1, category);
             return query.getResultList();
        }
        finally {
            if (em != null) {
                em.close();
            }
        }
    }
}

上述的DAO不对Spring产生任何依赖，而它就如同使用Spring的 JpaTemplate 那样，仍然非常适合 在Spring的application context中进行配置。此外，这样的DAO可以利用注解来要求缺省EntityManagerFactory 的注入：

注意：作为显式定义PersistenceAnnotationBeanPostProcessor的另一种方法， 可以考虑在应用程序上下文配置中使用Spring 2.5的context:annotation-config XML元素。 它会自动为基于注解的配置注册Spring所有标准的后置处理器（包括CommonAnnotationBeanPostProcessor等等）。

这类DAO的主要问题在于每次总是从工厂中获取一个新的 EntityManager 实例。 这一点可以通过对 EntityManager 而不是factory进行注入来解决：

public class ProductDaoImpl implements ProductDao {

    @PersistenceContext
    private EntityManager em;

    public Collection loadProductsByCategory(String category) {
       Query query = em.createQuery("from Product as p where p.category = :category");
       query.setParameter("category", category);
       return query.getResultList(); 
    }
}

注意：@PersistenceContext注解有一个可选的属性type，它的默认值是 PersistenceContextType.TRANSACTION。该默认需要你接收一个“共享EntityManager”代理。 另一种方式，PersistenceContextType.EXTENDED则完全不同：它会产生一个所谓的“扩展EntityManager”, 这个不是线程安全的，因此不应该用在当前被访问的组件中，例如Spring管理的singleton bean。 扩展的EntityManager只能用在有状态的组件中，例如，在会话中，EntityManager的生命周期与当前事务无关，完全取决于应用程序。

方法级和属性级的注入

表明依赖注入的注解(例如@PersistenceUnit和@PersistenceContext)能被用于类内的属性或者方法， 这就叫做“方法/属性级注入”。属性级注解的使用十分简单、简洁，而方法级注解则允许处理注入的依赖。 这两种情况对成员可见性(public, protected, private)均没有要求。

那么类级的注解又会怎么样呢？

在JEE 5平台上，它们是用于依赖声明，而非资源注入。

被注入的 EntityManager 由Spring管理（能够感知当前的事务）。 值得注意的是，即使这种新的实现更倾向于方法级别的注入（使用EntityManager 而不是 EntityManagerFactory）， 对于注解的使用，application context的XML配置则无需任何改变。

这种DAO风格的主要优点在于它仅仅依赖JPA，而无需依赖任何的Spring的类。除此之外，由于JPA的注解可被理解，注入能够被Spring容器自动应用。 从无入侵性的角度来说，这一点非常有吸引力，它对于JPA开发者来说也更自然。

12.6.4. 异常转化

然而，DAO不仅会抛出普通的 PersistenceException 异常（这是一个无需声明和捕获的unchecked exception）， 还会抛出诸如IllegalArgumentException 和 IllegalStateException 之类的异常。 这意味着，DAO的调用者只能以普通的错误来处理这些异常，除非完全依赖JPA自身的异常体系。因而，除非你将DAO的调用者绑定到具体的实现策略上去， 否则将无法捕获特定的异常原因（诸如乐观锁异常）。这种折中平衡或许可以被接受，如果你的应用完全基于JPA或者无需进行特殊的异常处理。不过， Spring提供了一个允许你进行透明的异常转化的解决方案：通过使用 @Repository 注解：

@Repository
public class ProductDaoImpl implements ProductDao {

    // class body here...

}

后置处理器将自动地寻找所有的异常转化器（PersistenceExceptionTranslator 接口的实现）， 并通知所有标有 @Repository 注解的bean，从而能够使得被找到的异常转化器能够在抛出异常时进行相应的异常转化工作。

总之：DAO能够基于普通的Java持久层API和注解来实现，但同样也能享受到由Spring管理事务、IoC和透明的异常转化 （转化成为Spring的异常体系）等好处。