Use Apache OPENJPA to develop EJB 3.0 applications, part 8th

Development and deployment of OPENJPA applications in Java EE environment

In part 1th of this series: OpenJPA and EJB 3.0 introduced OpenJPA, it was mentioned that "OpenJPA can function as a stand-alone persistence layer framework, or it can be easily integrated with other Java EE application frameworks or compliant with the EJB3.0 standard container", In the previous articles in this series, we have just explained how to work with OpenJPA as a stand-alone persistence layer framework, and in this article we will learn how to develop entity beans using OpenJPA in the JBoss application server, and to encapsulate entity bean operations with Sessionbean , the development, deployment process that is accessed through the local interface on the client.

Into Java EE

OpenJPA is a standard JPA framework, so it can be integrated by any EJB3.0 container as an implementation of JPA. For example, we can switch the JPA implementation framework in the JBoss application server from the system default Hibernate to OpenJPA, and we can switch the JPA implementation framework for Websphere, WebLogic, and so on from the system default framework to OpenJPA.

You need to complete several transformations of the OpenJPA container Java EE container, as opposed to the OpenJPA runtime as a stand-alone framework:

The form of deployment into an EJB jar or EAR;OPENJPA application in a Java EE environment is either an EJB jar or an EAR, and is no longer a stand-alone Java application or WEB application in a Servlet container.

Use a system-level JDBC data source to delegate transaction processing to JTA transactions;

In the previous articles, when we developed a OpenJPA application that provided a direct access to the JDBC configuration of the database in the OpenJPA configuration file Persistence.xml file, we also needed to deal with Entitymanager.gettransaction (). The processing transaction displayed by a statement such as Begin (), entitymanager.gettransaction (). Commit ().

In the Java EE environment, JDBC is typically managed by the container, and JDBC-accessed transactions often use container management, which allows for greater flexibility and maximizes the use of container features to make enterprise applications more robust. Our primary task in OpenJPA container Java ee container is to switch the application-level JDBC data source in OpenJPA to the JDBC data source of the Java EE container, and to delegate transaction processing to the JTA transaction provided by the Java EE container, without The processing transaction that is displayed using a statement such as Entitymanager.gettransaction (). Begin (), entitymanager.gettransaction (). Commit ().

Inject Entity manager Factory or Entity Manager

In the previous articles, before we developed the manipulation entities in the OpenJPA application, we needed to create entitymanagerfactory objects through the persistence Createentitymanagerfactory method, and then create Entitymanager the object after the action entity.

However, as required by the JPA section of the EJB3.0 specification, JPA applications in the Java EE container should obtain Entity manager Factory or Entitymanager through dependency injection, or you can choose to Entity Manager Factory, or Entitymanager, is bound to Jndi, which is obtained through Jndi in code, rather than by the persistence createentitymanagerfactory method.

To switch the OpenJPA application to the Java EE environment, we need to inject Entity Manager Factory or Entitymanager object into OpenJPA, or Entity Manager Factory or Entitymanager is bound to JNDI, depending on how the Java EE container is supported and the developer's hobby. In addition, the code for the corresponding part of the OpenJPA application needs to be modified to accommodate changes in the Java EE container end.

Using session beans to encapsulate Entitybean access

In the previous articles, the entities generated in the OpenJPA application were called directly from the Java code on the client, whereas entities in the Java EE container were definitely not directly accessible by client code, and the entities in the Java EE container could not be accessed by the EJB3.0 specification and EJB2 .1 are bound to JNDI like entities, so our choice is to use session beans to encapsulate Entitybean access.