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.

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).

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.

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.

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.

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.

The portlet application can use servlets and JavaServer Pages (JSP) in addition to portlets. These Java 2 Enterprise Edition (J2EE) resources can be created especially for the portlet application, or they can be part of a port of an existing J2EE application. Existing servlets and JSP will probably need to be edited to conform to the portlet markup rules for a content fragment. In this chapter, we discuss using servlets and JSP with a portlet. Most portlets will use JSP or another page display technology such as Apache Velocity to render content. Rendering content directly from a portlet is just as awkward as displaying HTML output from a servlet.

Most portal application deployments require a search engine. Portals usually unify content and applications from across an organization, and users may not know where to go to find their information. Deploying a well-thought-out, integrated search engine inside your portal is not just about the search engine technology used—some thought and design has to go into the overall information architecture of the portal and its component portlet applications.

Every web site that has more than a few pages requires some attention to be given to information architecture, including navigation, a site map, and a search engine. The JavaEdge application needs a search engine that can be plugged into our existing web infrastructure. To avoid maintaining two different technology stacks on our servers, any search engine that we decide to use should be deployable into Tomcat, WebLogic, WebSphere, or another J2EE application server or servlet container. Also, we need something that can be easily customized to match the look and feel of our site.

This book will demonstrate the use of freely available Java Open Source (JOS) development frameworks for building and deploying applications. Specifically, we will focus on the JOS development frameworks available from the Apache Software Foundation’s Jakarta group (http://jakarta.apache.org).

Building an application is more than just compiling the source code. Ideally, building an application would comprise all the steps required to produce readily consumable artifacts. But we must notice that different audiences are going to require different consumable artifacts. For example, the development team may require Javadocs and last night’s test results as artifacts, whereas the QA team may not care about the Javadocs as much as the revision log. The end user may not care about either of these and just want a URL in the case of an online application or an executable in the case of a traditional program. So building an application may need to produce a whole range of artifacts, each consumable by one or more of the target audiences of the build.

So far we’ve seen how the use of development frameworks and judicious use of design patterns can help to separate the concerns of our web applications. For the most part with concentrated on the main core of our application, and how to separate our application logic. Although not necessarily as important as the business logic, we can take this process one step further and separate our application’s Java code from our presentation through the use of templates. So in this chapter, we will describe the problems that template engines can solve, and how to use one such template engine, Velocity.