With the project properly configured, we can use the database tables as a starting point to create the entities.

To generate the classes:

We now have the base code to execute a query against the database. Let's check the relevant pieces of code of one of the classes, Theater:

@Entity
@Table(name="theater")
public class Theater implements Serializable {

This is how you create a JPA entity—you just need to annotate your POJO class with javax.persistence.Entity and javax.persistence.Table, and it's done.

A few more details about the generated entity class that are implicit to the code we just saw:

Then we have the declaration of the primary key, which is also pretty straightforward:

@Id
@GeneratedValue(strategy=GenerationType.TABLE)
private int id;

The Id annotation states that the field is a primary key, and @GeneratedValue indicates the strategy and parameters the persistence provider must use to generate unique identifiers when inserting a record. This is the same as declaring a generated-value tag inside the orm.xml descriptor file. Use this file if you don't want to annotate your classes or if you want to change a definition without having to edit source code and repacking the binaries.

Do you remember that we left out a couple of tables at the JPA Generate Entities wizard? One of them, the SEQUENCE table, is the default table used by EclipseLink when you select AUTO or TABLE as the strategy. This table must have a record prior to issuing an insert command, depending on the strategy selected, with specific values:

The last snippet of code worth mentioning is the one that declares the relationship between the Theater and Room entities:

//bi-directional many-to-one association to Ticket
@OneToMany(mappedBy="theater")
private List<Ticket> tickets;

The JPA wizard's default behavior when creating relationships is to make them bi-directional. So, if you check the Ticket.java file, you will find the reference back to Theater:

@ManyToOne
@JoinColumn(name="theaterRef")
private Theater theater;

The basic entities and their mappings are ready. The usage of MySQL's auto_increment and foreign keys were left out on purpose to show how relationships and identities are manually created. In the next chapter, we're going to see how they are taken into account when generating classes.

A named query is also called a static query, in the sense that its declaration is attached to the entity either by using the named query annotation or by named-query tags inside a JPA mapping file that maps the entity.

To keep things simple, let's see how we declare a query using annotations:

@Entity
@NamedQuery(name=Movie.findAll, query="SELECT M FROM Movie M")
public class Movie implements Serializable {
   public final static String findAll = "Movie.FindAll";
...

This code snippet returns all the Movie instances available. This is a very basic query that we're going to use to check if all the persistence components are correctly configured. There are several possibilities to explore when creating a query—inner joins, aggregation functions, inheritance, subqueries, and so on—and we will use some of them as we evolve our sample applications.

When we ask the persistence provider to execute a named query, we need to inform the name of the desired query. You can have more than one NamedQuery annotation inside a class, provided you group them using the @NamedQueries decoration:

@Entity
@NamedQueries({
   @NamedQuery(name=Movie.findAll, query="SELECT M FROM Movie M")
   @NamedQuery(name=Movie.findPremiere, query="SELECT M FROM ...")
})

There is a similar query declared inside the Theater class to retrieve all Theater instances available:

@NamedQueries({
   @NamedQuery(name=Theater.findAll, query="SELECT T FROM TheaterT")
})
public class Theater implements Serializable {
   public final static String findAll = "Theater.FindAll";
...

The last piece of configuration we have to tweak is the persistence.xml file used by the persistence provider to identify which connections must be used to access each entity and fine-tune its behavior.

Here are the file contents after creating the entities using the wizard:

<persistence version="2.0">
   <persistence-unit name="StoreBO">
      <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
      <class>com.packt.domain.store.Customer</class>
      <class>com.packt.domain.store.Movie</class>
      <class>com.packt.domain.store.Theater</class>
      <class>com.packt.domain.store.Ticket</class>
   </persistence-unit>
</persistence>

The persistence unit's name is the same as the project StoreBO; no need to change it. But, do you remember that we didn't select a connection when creating the project? As the JPA Project wizard does not allow us to choose a WebLogic data source, we now have to configure it:

As the entities were explicitly declared by the JPA wizard, we can disable package scanning. To do so, perform the following steps:

Save the file, and it's done.

Now we just have to pack the project and deploy it to the WebLogic Server as an optional package.

To make the library adherent to the standard, create the MANIFEST.MF file inside the src/META-INF folder and add these lines:

Manifest-Version: 1.0
Extension-Name: storeBO
Specification-Version: 1.0
Implementation-Version: 1.0.0

This is the same configuration we made when creating PrimeFaces' shared library in the previous chapter, and it's the only requirement to make a plain JAR file an optional package.

You may use the JAR Export wizard provided by Eclipse to generate the package or create it using an Ant script as the example in the next info box, or a compression application, such as WinZip or 7Zip. Either way, make sure the packaged MANIFEST.MF file has exactly the same content (and sequence of lines) as we just showed. Without the specific tags we added in that specific order, the deployment will complete successfully but WebLogic will not be able to resolve the dependency when deploying a project that references the optional package.

<?xml version="1.0" encoding="UTF-8"?>
<project>
   <property name="jarName" value="StoreBO.jar"/>
   <target name="clean">
      <delete dir="build"/>
   </target>
   <target name="compile">
      <mkdir dir="build/classes"/>
      <javac srcdir="src" destdir="build/classes"/>
   </target>
   <target name="jar">
      <mkdir dir="build/jar"/>
      <jar manifest="src/META-INF/MANIFEST.MF"destfile="build/jar/${jarName}"basedir="build/classes" />
   </target>
</project>

The final package must have the structure depicted in the following figure:

Notice that we didn't add the persistence.xml file to the JAR package—the file must be present in the EJB project using the entities, not here.

Based on the rule above, here are some of the places you can place the persistence.xml file:

If you're going to pack a persistence.xml file into a JAR, make sure it is inside the META-INF folder, and that this folder is at the root of the package. Anywhere else, the container will not find it.

The last step to complete the enablement of an optional package is to register it in the WebLogic Server. To do so, access the WebLogic Administration Console and perform the following steps:

After the deployment is completed, the Deployments screen is reloaded and you should see the new module and its State as Active as shown in the following screenshot:

If you followed the installation procedures in Chapter 2, Setting Up the Environment, you may be thinking that if an optional package is basically the same as a shared library, why didn't we create it the same way we did earlier using Eclipse/OEPE?

Well, the two main reasons:

Now that we have our entities available, let's create the main project and the basic code to test the environment.