Using the Java Persistence API with a Visual JSF Web Application

I just finished trying out the Using the Java Persistence API with a Visual JSF Web Application tutorial. It’s pretty straightforward and easy to follow. The effect was positive. I was not immediately successful at runtime.

Here’s the problem I encountered:

In the section “Creating a Java Persistence Entity Class Representing the Users Database Table”, either a step was left out, or there was some sort of glitch. This is what my Persistence Units (persistence.xml) screen looked like after I completed this step:


Note that the “Include Entity Classes” box is empty. When you try to run the web app, you get the following error:

Caused by: Exception [TOPLINK-8034] (Oracle TopLink Essentials - 2.0 (Build b58g-fcs (09/07/2007))): oracle.toplink.essentials.exceptions.EJBQLException
Exception Description: Error compiling the query [select c from Users as c]. Unknown abstract schema type [Users].

The solution is to open persistence.xml (Project–>TestModelApp–>Source Packages–>META-INF–>persistence.xml) and click the “Add Class” button. Select com.samples.model.Users. Rebuild. Redeploy.

The JPA design is a bit of an adjustment to me. I’m just getting used to seeing annotations in my beans (for Java Web Services), and now I have to adjust to seeing SQL code. It’s like the Data Access Object(DAO) and the bean are combined in one class. It’s different, but I’m not sure if it is good, bad, or just…well, different. I’m curious about how this will look in more complex data models where one bean may contain references to several other beans as instance variables. Just how many database transactions will it take to build one of these? As I’m writing this, it’s occurring to me that the answer is, “Well, just as many as there would be if you had written the JDBC code yourself, dumbass!”. Perhaps that’s true.

The main thing to take away from this is that

  1. I didn’t use a DataProvider (proprietary to Netbeans)
  2. I was able to bind the Persistence Unit in the visual designer (not drag n drop, but good enough)
  3. My data access (Persistence Units) are reusable
  4. Although I’m not sure if the JPA classes constitute a separate tier, at least they’re kept in a separate Netbeans Project so that they can be freely associated with other applications without duplication.

This is positive. I may even like it.

One comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s