Package org.apache.mailreaderjpa

MailReader Database Java Persistence Architecture (JPA) Entity Classes.

See:
Description

Class Summary

Protocol	JPA entity class for the MAILREADER_PROTOCOLS table.
Subscription	JPA entity class for the MAILREADER_SUBSCRIPTIONS table.
User	JPA entity class for the MAILREADER_USERS table.

Package org.apache.mailreaderjpa Description

MailReader Database Java Persistence Architecture (JPA) Entity Classes.

This package contains entity classes that correspond to relational database tables for a persistent version of the "user" and "subscription" data from the original Struts MailReader example application, where the "database" was represented as an XML file. See the specification for more information about the Java Persistence Architecture.

This library comprises a persistence unit named MailReaderJpa, whose characteristics are described in a META-INF/persistence.xml file included in the JAR. As delivered, the persistence unit presumes deployment into a Java EE 5 based application server, using a configured JDBC DataSource named jdbc/mailreader. The details of how this maps to an actual database are defined in the configuration files (or through the administration console) for your application server. It is also possible to define a persistence unit that uses a standalone JPA implementation, and perhaps even an embedded database. See the commented out example in persistence.xml for a flavor of how this might look.

Java Persistence Architecture technology can be used in a number of different ways. For ease of deployment of example applications using this library, this persistence unit is configured to create the appropriate tables if necessary, with the characteristics of the tables and columns being configured from annotations in the (hand created, with tool assistance) entity classes. A common alternative scenario will be where you have existing database schemas, and use a tool like NetBeans 5.5 to automatically create entity classes from existing tables. Both techniques represent best practice, as does the concept of keeping a persistence unit (and its corresponding entity classes) packaged as a separate Java class library that can be reused across multiple projects.