You are on page 1of 5

WEBANNOTATIONS During the lifetime of a typical web application, a number of events take place, such as HTTP requests are

created or destroyed, request or session attributes are added, removed, or modified, and so on and so forth. The Servlet API provides a number of listener interfaces we can implement in order to react to these events. All of these interfaces are in the javax.servlet package. The following table summarizes them: LISTENER INTERFACE
ServletContextListener ServletContextAttributeListener

DESCRIPTION
Contains methods for handling context initialization and destruction events. Contains methods for reacting to any attributes added, removed, or replaced in the servlet context (application scope). Contains methods for handling request initialization and destruction events. Contains methods for reacting to any attributes added, removed, or replaced in the request. Contains methods for handling HTTP session initialization and destruction events Contains methods for reacting to any attributes added, removed, or replaced in the HTTP session.

ServletRequestListener ServletRequestAttributeListener HttpSessionListener HttpSessionAttributeListener

Summary
This chapter covered how to develop, configure, package, and deploy servlets. We also covered how to process HTML form information by accessing the HTTP request object. Additionally, forwarding HTTP requests from one servlet to another was covered, as well as redirecting the HTTP response to a different server. We also discussed how to persist objects in memory across requests by attaching them to the servlet context and the HTTP session. Finally, we covered all the major new features of Servlet 3.0, including configuring web applications via annotations, pluggability through web-fragment.xml, programmatic servlet configuration, and asynchronous processing.

Database Connectivity
Any non-trivial Java EE application will persist data to a relational database. In this chapter, we will cover how to connect to a database and perform CRUD operations (Create, Read, Update, and Delete). There are two Java EE APIs that can be used to interact with a relational

Some of the benefits of prepared statements include: • Prepared statements are compiled into the RDBMS the first time they are executed. The most common way of interacting with a database through JDBC is through the java. insert. update. JPA replaced entity beans in Java EE 5 (of course. The executeQuery() method is used to issue select statements to the database and returns an instance of java. Some of the topics covered in this chapter include: • Retrieving data from a database through JDBC • Inserting data into a database through JDBC • Updating data in a database through JDBC • Deleting data in a database through JDBC • Retrieving data from a database through JPA • Inserting data into a database through JPA • Updating The Java Database Connectivity (JDBC) API is the standard API used for Java applications to interact with a database.database: the Java Database Connectivity (JDBC) API and the Java Persistence API (JPA).PreparedStatement interface.sql. Although JDBC is not part of the Java EE specification.PreparedStatement interface has two methods that are very frequently used to send queries to the database: executeQuery() and executeUpdate(). The Java Persistence API The Java Persistence API (JPA) was introduced to Java EE in version 5 of the specification. it is used very frequently in Java EE applications. The Java EE container knows these classes are entities because they are decorated with the @Entity annotation. In the following sections. update. Like its name implies.ResultSet containing the rows returned from the query.sql.0's Bean Validation support JDBC JDBC allows us to send queries to a database to perform select. and delete statements to the database. for backwards compatibility. . The executeUpdate() method is used to issue insert.sql.0 Criteria API • Automating data validation through JPA 2. therefore increasing performance • Prepared statements are immune to SQL injection attacks • Prepared statements free us from explicitly adding single quotes (') to our SQL statements to handle character values The java. data in a database through JPA • Deleting data in a database through JPA • Building queries programmatically through the JPA 2. and delete operations. It returns an int value corresponding to the number of rows affected by the query. Both these APIs will be discussed in this chapter. entity beans are still supported). Using prepared statements through this interface offers a number of benefits over using standard JDBC statement objects. we illustrate database interaction through these two methods. it is used to persist data to a Relational Database Management System. Java EE Entities are regular Java classes.

Entities are rarely isolated. update. Therefore. This is because a customer can place many orders. As we will soon see. In the CUSTOMERDB database. one-to-one mapping between the LOGIN_INFO and CUSTOMERS tables is unidirectional. they are related to other entities. This is because an order can contain many items and an item can be found in many orders. one-to-many entity relationships can be bidirectional (one entity contains a many-toone relationship and the corresponding entity contains an inverse one-to-many relationship). This means that each customer has exactly one corresponding row in the LOGIN_INFO table. One-to-many relationships defined in an RDBMS are typically unidirectional. we saw how to retrieve. For example. there is a many-to-many relationship between the ORDERS table and the ITEMS table. and many-to-many relationships. Many-to-many relationships In the CUSTOMERDB database. in the CustomerDB database. With SQL. there is a many-to-many relationship between the ORDERS table and the ITEMS table. There is also a one-to-many relationship between the CUSTOMERS table and the ORDERS table. but not the other way around. we discuss how to establish relationships between JPA entities. this fact does not stop us from creating a bidirectional one-to-one relationship between the Customer entity and the LoginInfo entity. and delete single entities from the database. insert. One-to-one relationships One-to-one relationships occur when an instance of an entity can have zero or one corresponding instance of another entity. Just like when defining a unidirectional one-to-many relationship in an RDBMS. One-to-many relationships With JPA. the annotation used to decorate the appropriate setter method is @ManyToOne. in the vast majority of cases. We can map this relationship by adding a new Collection<Item> field to the Order entity and decorating it with the @ManyToMany annotation. The "many" part of the relationship is the one containing a foreign key to the "one" part of the relationship. one-to-many. in JPA the "many" part of the relationship is the one that has a reference to the "one" part of the relationship. Additionally. . One-to-one entity relationships can be bidirectional (each entity is aware of the relationship) or unidirectional (only one of the entities is aware of the relationship). as making them bidirectional usually results in denormalized data. there is a one-to-one relationship between the LOGIN_INFO and CUSTOMERS tables. one-to-many relationships are defined by foreign keys in one of the tables. many-to-one. Entities can have one-to-one.Entity relationships In the previous section. as the LOGIN_INFO table has a foreign key to the CUSTOMERS table. In the next few sections.

it has some problems that make working with it more difficult than necessary. For starters. JPQL is not type safe. As this table does not have a surrogate primary key. this table has an additional column called ITEM_QTY. Additionally. we discuss some of these new features: Criteria API One of the main additions to JPA in the 2.0 of the JPA specification introduces some new features to make working with JPA even easier. Instead. updating. a column in the database that is known to be unique across rows is used as the primary key. To get around the JPQL limitations described in the previous paragraph. some databases are not designed this way. There is one table in the CUSTOMERDB database that does not have a surrogate primary key—the ORDER_ITEMS table.Composite primary keys Most tables in the CUSTOMERDB database have a column with the sole purpose of serving as a primary key (this type of primary key is sometimes referred to as a surrogate primary key or as an artificial primary key). which stores the quantity of each item in an order. the Criteria API was introduced to JPA in version 2. then a combination of two or more columns is used as the table's primary key. The Criteria API is meant as a complement to the Java Persistence Query Language (JPQL). without having to rely on JPQL. Whenever we need to search for an entity by a field other than the entity's primary key. the combination of the ORDER_ID and ITEM_ID columns must be unique. We could write a JPQL query in which our where clause could have a string value for a numeric property and our code would compile and deploy just fine. In this table.0 Version 2. JPQL is an SQL-like language used for retrieving. The Criteria API allows us to write JPA queries programmatically. If there is no column whose value is not guaranteed to be unique across rows. In addition to having foreign keys for these two tables. the JPA entity mapping to it must have a custom primary key class. Although JPQL is very flexible. New features introduced in JPA 2. Java Persistence Query Language All of our examples that obtain entities from the database so far have conveniently assumed that the primary key for the entity is known ahead of time. JPQL queries are stored as strings and the compiler has no way of validating JPQL syntax. We all know that frequently this is not the case. Bean Validation support .0 of the specification. However. It is possible to map this kind of primary key to JPA entities by using a primary key class. we must use the Java Persistence Query Language (JPQL). and deleting entities in a database. This table serves as a join table between the ORDERS and the ITEMS tables.0 specification is the introduction of the Criteria API. In the following sections.

We then discussed some new JPA 2. we covered how to use JPA composite primary keys by developing custom primary key classes. We also covered how to retrieve entities from a database by using the Java Persistence Query Language (JPQL). Setting a Java class as an entity by decorating it with the @Entity annotation was also covered. and many-to-many relationships between JPA entities was covered as well.Another new feature introduced in JPA 2. persist.persistence. Defining both unidirectional and bidirectional one-to-one. and Bean Validation that allows us to easily validate input by simply annotating our JPA entity fields . Bean Validation.EntityManager interface to find. Additionally. Using the javax.sql.0 is support for JSR 303. as well as declaring an entity's primary key via the @Id annotation. using dependency injection to inject a DataSource into an object was also covered. and update JPA entities was also covered. We covered how to obtain data from the database by using JDBC via the executeQuery() method defined in the java. We also covered how to insert. Additionally.PreparedStatement interface. the Metamodel API that allows us to take advantage of Java's type safety when working with JPA. and delete data in the database via the executeUpdate() method defined in the same interface. Summary This chapter covered how to access data in a database via both the Java Database Connectivity (JDBC) and through the Java Persistence API (JPA). Additionally. Bean Validation support allows us to annotate our JPA entities with Bean Validation annotations. These annotations allow us to easily validate user input and perform data sanitation.0 features such as the Criteria API that allows us to build JPA queries programmatically. one-to-many. We also covered how to map entity fields to database columns via the @Column annotation. update. we covered how to map an entity to a database table via the @Table annotation.