Search

In Chapter 5, we discussed the need to create mappings between the database model and the object model. Mappings can be created as separate XML files, or as annotations inline with the source code for your POJOs. In this chapter, we discuss the use of annotations, and in the next chapter, we will discuss the use of XML files.

The purpose of Hibernate is to allow you to treat your database as if it stores Java objects. However, in practice, relational databases do not store objects – they store data in tables and columns. Unfortunately, there is no simple way to correlate the data stored in a relational database with the data represented by Java objects.

Hibernate provides a number of capabilities beyond the simple “native Hibernate API.” In this chapter, we are going to discuss using the standard JPA configuration resource, Hibernate’s object validation facilities, and object lifecycle events — along with a few other tricks.

We’ve seen a lot about how to use Hibernate, including a series of example models, but none of this has really demonstrated how Hibernate would be used in the "real world." All of our running code has been embedded in tests, which isn’t a bad thing for development, but this isn’t a good way to make it clear how to integrate Hibernate into applications people are likely to use.

Your application will often need to process only a subset of the data in the database tables. In these cases, you can create a Hibernate filter to eliminate the unwanted data. Filters provide a way for your application to limit the results of a query to data that passes the filter’s criteria. Filters are not a new concept — you can achieve much the same effect using SQL database views or, well, named queries — but Hibernate offers a centralized management system for them.

You may have noticed that the Session object is the central point of access to Hibernate functionality. We will now look at what it embodies and what that implies about how you should use it.

Hibernate provides three different ways to retrieve data. We have already discussed HQL and the use of native SQL queries; now we add criteria.

In this chapter, you’ll take another look at some of the steps necessary to get the example from Chapter 1 up and running. You’ll also build a somewhat larger application from scratch. All of the code in this book is available for download from the Apress site (www.apress.com).

In the last chapter, we discussed how the Hibernate session is used to interact with the database. Some of the session's methods take query strings in their parameter lists or return Query objects. These methods are used to request arbitrary information from the database. In order to fully show how they're used, we must introduce the Hibernate Query Language (HQL), used to phrase these requests. As well as extracting information (with SELECT), HQL can be used to alter the information in the database (with INSERT, UPDATE, and DELETE). We cover all of this basic functionality in this chapter. Note: Hibernate's query facilities do not allow you to alter the database structure.

Integrating Hibernate into a Java application is easy. The designers of Hibernate avoided some of the more common pitfalls and problems with the existing Java persistence solutions, and created a clean but powerful architecture. In practice, this means that you do not have to run Hibernate inside any particular Java EE container or framework. As of Hibernate 5.2, Java 8 or later is required, thanks to the integration of the date and time API and other such useful features.

In this chapter, we discuss the life cycle of persistent objects in Hibernate. These persistent objects can be POJOs without any special marker interfaces or inheritance related to Hibernate. Part of Hibernate’s popularity comes from its ability to work with a normal object model.

Most significant development projects involve a relational database. The mainstay of most commercial applications is the large-scale storage of ordered information, such as catalogs, customer lists, contract details, published text, and architectural designs.

Hibernate doesn’t limit you to using purely relational databases; Hibernate OGM stands as a project that can carry an object model into the realm of the NoSQL datastore, allowing developers to use a familiar mechanism to access multiple types of storage.

In addition to annotations, Hibernate supports the use of XML mapping files to describe the relationship between the object model and the database. A mapping file can map a single class or multiple classes to the database. The mapping can also describe standard queries (in HQL and SQL) and filters.

Many projects you work on with Hibernate will be with existing databases. In contrast to some of the examples we have shown so far where we have created our database from the Java object model, this example project starts with a database that already has a schema. In our example in this chapter, we are going to create a new Java object model for the database, using annotations for our Hibernate mappings, and then run some queries that use the Hibernate Query Language.

Security and Single Sign-On (SSO) are not unique to portlets, but when considering their implementation you must take into account some special advantages, disadvantages, and responsibilities.

Because a portlet is generally a minor part of a larger application (the portal), most of the time it will have a strictly limited canvas on which to present its information. So it is vital that the portlet should make the best possible use of this.

In this chapter, we discuss the Web Services for Remote Portlets (WSRP) standard. WSRP defines a standard way for portals to handle input and display for a portlet running on a remote portal server. With WSRP, one portal server (or a cluster) is responsible for hosting a portlet, and other portal servers can display the portlet as if it were installed locally. We present an overview of the WSRP standard, along with the steps you need to take as a portlet developer to use WSRP.

In this chapter we take an existing web application, the YAZD forum software, and adapt it to provide a portlet front end. Initially, we install the forum software in its unaltered state; then we show the decisions and changes we make in the process of building the portlet.

The portlet API defines several interfaces for working with preferences and settings for the portal, the portlet application, and the current user of the portlet. Portlets access information about the portal that they are currently running in through the PortalContext object. The configuration settings for the application are available from the PortletConfig class. The portlet accesses and persists individual settings and preferences transparently with the PortletPreferences object.

Many portal applications will have a business requirement to provide charting, reporting, or other analysis tools. These could be part of a sales forecasting system, a financial reporting tool, or a customer service application. In one possible architecture, basic functionality for accessing and modifying charts or reports could belong to a front-end portlet application, with an enterprise information system (EIS) on the back-end.

As we’ve seen in earlier chapters, portlets are conceptually very similar to servlets. Like servlets, they can only operate within a container. Both have obligations that their design must satisfy to allow them to interact with their container, and both demand clearly specified behavior from their containers.

This book is for software developers and designers who develop Java applications for portals. We cover version 1.0 of the Java portlet API, also known as Java Specification Request (JSR) 168. Portlets are the individual components that provide content for a portal. Portals aggregate one or more portlets into web pages, which are usually personalized or customized for individual users or groups of users. Some portals also support mobile devices and voice support.

In this chapter, we describe how portlets can aggregate links to content on external web sites using the group of standards known as RSS. We also discuss how the content of your own portal could be syndicated for convenient inclusion in external sites using the same mechanism.