Catálogo de publicaciones - libros

It is a simple exercise to package and deploy persistence applications using the Java Persistence API. In most cases it is just a matter of adding a very short persistence.xml file to the JAR containing the entity classes.

In this chapter we described how to configure the persistence unit in the Java EE server environment using the persistence.xml file and how in some cases the name may be the only setting required. We then explained when to apply and how to specify the transaction type, the persistence provider, and the data source. We showed how to use and specify the default orm.xml mapping file and then went on to use additional mapping files within the same persistence unit. We also discussed the various ways that classes may be included in the persistence unit and how to customize the persistence unit using vendor-specific properties.

We looked at the ways that persistence units may be packaged and deployed to a Java EE application as part of an EJB archive, a web archive, or a persistence archive that is accessible to all of the components in the application. We examined how persistence units may exist within different scopes of a deployed Java EE application and what the name-scoping rules were.

Finally we compared the configuration and deployment practices to deploying an application to a Java SE environment.

In the next chapter we will consider the accepted and best practices for testing applications that use persistence.

In this chapter we started with an exploration of testing enterprise applications and the challenges that have traditionally faced developers. We also looked at the different types of testing performed by developers, quality engineers, and customers, and we refined our focus to look specifically at developer tests for EJB 3.0 and Java Persistence API applications.

In the section on unit testing, we looked at how to test entity classes and then pulled back to look at how to test session beans in combination with entities in a unit test environment. We introduced the concept of mock objects and explored how to test code that depends on the entity manager without actually using a real entity manager.

In our discussion of integration testing, we discussed how to get the entity manager up and running in JUnit tests in the Java SE environment and the situations where it makes sense to use this technique. We covered a number of issues related to the entity manager, including how to safely seed a database for testing, how to use multiple mapping files for different database configurations, and how to minimize the number of database connections required for a test suite.

We looked at how to use session beans in integration tests and how to deal with dependency-injection and transaction-management issues. For transaction management, we looked at how to emulate container-managed and bean-managed transactions, as well as how to simulate persistence context propagation in a test environment. We concluded with a summary of some best practices to consider when building Java EE applications using the Java Persistence API.

In the next chapter we will look at how to migrate existing EJB 2.1 and JDBC applications to the Java Persistence API.

Migrating the persistence layer of an application from one technology to another is rarely a trivial task. The differences between EJB container-managed entity beans and the lightweight entities of the Java Persistence API could make the task of migration tricky. And yet, despite these challenges, it is possible not only to extract enough information out of entity beans to bootstrap an object-oriented domain model but also to leverage the same design patterns that made entity beans easier to work with as the very tool to replace them.

In our discussion of entity beans, we looked at how to use the existing bean as a template for the new entity, using the business interface, bean class, and XML descriptor of the entity bean in the process. We also looked at the home interface and how we can introduce stateless session beans to emulate the functions of the home interface with minimal impact to application code.

We then touched on the migration of ORM and JDBC technologies to the Java Persistence API. While existing ORM migrations will largely depend on the support provided by the vendor, existing JDBC applications can be tackled by refactoring to existing Java EE design patterns before making the switch to the Java Persistence API.

Finally we looked at a catalog of Java EE design patterns related to persistence. Though not an exhaustive list, we looked at many of the major design patterns in use today and how they can be leveraged to safely introduce the Java Persistence API while minimizing the overall impact to the existing application.