Once your persistence configuration is defined, the only change we need to do in our application is adding the javax.persistence annotations to our property POJO. This will make it suitable to map the database table with its same name, which will store the key/value pair entered by the user:
@Entity public class Property ’7b @Id @Column(name=”key”) private String key;
@Column(name=”value”) private String value;
// Getter & setters omitted for brevity ’7d
Our Session Bean needs to be changed as well. Taking inspiration from today’s caching systems, we are letting our application persist data into the storage (database), but we are using the in-memory cache to retrieve data from it. When the application is re- started, the in-memory cache will be filled with data queried from the database.
Nothing fancy, however; for our purpose it will be just fine.
@Singleton public class SingletonBean ’7b private List cache;
(unitName = “persistenceUnit”)
private EntityManager em;
@PostConstruct public void initCache()’7b this.cache = queryCache();
if (cache == null) cache = new ArrayList();
’7d public void delete()’7b Query query = em.createQuery(“delete FROM com.packtpub.chapter4.entity.Property”);
’7d public void put(String key,String value)’7b Property p = new Property();
’7d public List getCache() ’7b return cache;
’7d public List queryCache()’7b Query query = em.createQuery(“FROM com.packtpub.chapter4.entity.Property”);
List list = query.getResultList();
We have highlighted the sections of the code that have been modified to use data persistence. The most relevant section is the @javax.persistence.Persistence Context annotation, which references a JPA context defined into
persistence.xml. Once deployed, this application should persist data in your MySQL database:
In this example, we have created a Java EE 6 application made up of web components and EJBs using a single web application archive. That’s absolutely possible, since Java EE 6 enables mixing-and-matching front-end components and server-side components in a single web archive.
You can, however, consider deploying an application where the Web layer is separated from the business service layer. For example, supposing you were to deploy your EJBs and entities in a separated JAR file, then the right place for the persistence.xml file would be beneath the META-INF folder of your JAR archive:
Technically speaking, if you have multiple JAR files in your application, you can deploy the persistence.xml file in a single archive and refer to the persistence unit using the notation jarName#unitName.
For example, this application persistence unit could be referenced from another JAR using the following annotation:
By default, AS7 uses Hibernate 4.0 as a persistence provider. The Hibernate JARs are included under the modules folder in the org.hibernate path. If, however, your application requires a different version of Hibernate, such as 3.5 or greater, you can still bundle the JARs into your application.
Besides this, you need to set the jboss.as.jpa.providerModule property to hibernate3-bundled in your persistence.xml configuration file. So, the JPA deployer will detect the presence of a different version of the persistence provider and activate that version:
static-resources configuration: This comes into play when JBoss AS is used to serve static resources, such as HTML pages and images
jsp-configuration: This is used to configure and fine-tune the dynamic pages creation
We have then gone through an example that showed off how to package and deploy a Java EE 6 Web module on the application server.
We have stressed the correct location of the
persistence.xml file, which is required to be placed in the WEB-INF/classes/META- INF of your web application or in the META-INF folder of your JAR.
Having completed the application server standalone configuration, we will now move on in the next chapter to the domain configuration, which is one of the most appetizing new features of this release
Get Updates on Tech posts, Interview & Certification questions and training schedules