This is the third of a series of articles about Persistence with Spring. This article will focus on the configuration and implementation of Spring with JPA. For a step by step introduction about setting up the Spring context using Java based configuration and the basic Maven pom for the project, see this article.
The Persistence with Spring series:
- Part 1 – The Persistence Layer with Spring 3.1 and Hibernate
- Part 2 – Simplifying the Data Access Layer with Spring and Java Generics
- Part 4 – The Persistence Layer with Spring Data JPA
- Part 5 – Transaction configuration with JPA and Spring 3.1
No More Spring Templates
As of Spring 3.1, the JpaTemplate and the corresponding JpaDaoSupport have been deprecated in favor of using the native Java Persistence API.
Also, both of these classes are only relevant for JPA 1 (from the JpaTemplate javadoc):
Note that this class did not get upgraded to JPA 2.0 and never will.
As a consequence, it is now best practice to use the Java Persistence API directly instead of the JpaTemplate, which will effectively decouple the DAO layer implementation from Spring entirely.
Exception Translation without the template
One of the responsibilities of JpaTemplate is exception translation – translating the low level exceptions – which tie the API to JPA – into higher level, generic Spring exceptions.
Without the template to do that, exception translation can still be enabled by annotating the DAOs with the @Repository annotation. That, coupled with a Spring bean postprocessor will advice all @Repository beans with all the implementations of PersistenceExceptionTranslator found in the Container – to provide exception translation without using the template.
Exception translation is done through proxies; in order for Spring to be able to create proxies around the DAO classes, these must not be declared final.