Skip Headers
Oracle® Fusion Middleware Programming Enterprise JavaBeans for Oracle WebLogic Server
12c Release 1 (12.1.1)

Part Number E24972-02
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

8 Configuring the Persistence Provider in Oracle WebLogic Server

This chapter describes Oracle TopLink, the default persistence provider in Oracle WebLogic Server, and introduces how to use it. This chapter also tells how to set the default persistence provider in Weblogic Server, how to modify existing Kodo applications for use in the current release, and how to upgrade to a newer version of OpenJPA.

The following topics are covered:

Overview of Oracle TopLink

Oracle TopLink is the default persistence provider in WebLogic Server 12c and later. It is a comprehensive standards-based object-persistence and object-transformation framework that provides APIs, schemas, and run-time services for the persistence layer of an application.

The core component of TopLink is the EclipseLink project's produced libraries and utilities. EclipseLink is the open source implementation of the development framework and the runtime provided in TopLink. EclipseLink implements the following specifications, plus value-added extensions:

EclipseLink also provides support for Oracle Spatial and Oracle XDB mapping.

For more information about EclipseLink, including other supported services, see the EclipseLink project home at http://wiki.eclipse.org/EclipseLink and the EclipseLink Documentation Center at http://wiki.eclipse.org/EclipseLink/UserGuide.

In addition to all of EclipseLink, Oracle TopLink includes:

For information about developing, deploying, and configuring Oracle TopLink applications, see the following:

Specifying a Persistence Provider

You can specify what persistence provider to use for a persistence unit in the application code or by accepting the default persistence provider set for the WebLogic Server domain, as described in the following sections:

Setting the Default Provider for the Domain

Unless you specify otherwise, TopLink is used as the default persistence provider for a WebLogic Server domain. The default provider is used for any entities in an application that are not configured to use a different persistence provider. The default provider is used for both injected and application-managed entity managers and factories.

You can set the default provider in the WLS Administration Console or by directly setting JPAMBean.DefaultJPAProvider. In the Administration Console, the options are Oracle TopLink or Oracle Kodo.

Note:

Oracle Kodo JPA/JDO is deprecated in this release. Customers are encouraged to use Oracle TopLink, which supports JPA 2.0. Kodo supports only JPA 1.0.

For instructions on setting the default through the Administration Console, see "Configure the Default JPA Persistence Provider" in Oracle WebLogic Server Administration Console Help.

If you change the default provider, you must do the following for any deployed applications that do not specify a JPA provider:

  • Restart applications that use application-managed entity manager factories.

  • Redeploy applications that use injected entity manager factories or entity managers.

Specifying the Persistence Provider in an Application

A persistence provider specified in an application takes precedence over the default provider set for the WebLogic Server domain.

You can set the provider to use in the following ways:

  • Specify the provider in the <provider> element for a persistence unit in the persistence.xml file, for example:

    <persistence-unit name="example">
        <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
    ...
      </persistence-unit>
    
  • Specify the provider in the javax.persistence.provider property passed to the Map parameter of the javax.persistence.Persistence.createEntityManagerFactory(String, Map) method.

Using Oracle TopLink in Oracle WebLogic Server

For detailed information about using Oracle TopLink in WebLogic server, see "Using TopLink with WebLogic Server" in Oracle Fusion Middleware Solution Guide for Oracle TopLink.

Using Oracle Kodo in Oracle WebLogic Server

It is advantageous to use the default Oracle TopLink for your applications, due to its implementation of JPA 2.0, its enhanced set of features, its integration in WebLogic Server, and its integration with TopLink Grid. However, you may want to continue to use Kodo for existing applications that were written for use with Kodo. Although deprecated, Kodo is still included with WebLogic Server: you do not have to install it. You can set it as the default provider, as described in Specifying a Persistence Provider, or configure an application to use it.

Note:

Switching an application from one JPA provider to another usually involves more than just flipping a switch. Most obviously, if the application uses proprietary features of the original JPA implementation, that usage will have to change when moving to a different implementation.

In addition, differences in the implementations of a standard specification (that is, JPA) can affect the behavior of an application. Although Kodo and TopLink implement their JPA specifications, as do other conforming JPA implementations, each implementation makes its own decisions about unspecified details that can affect the behavior of the application using JPA. When making the switch from one JPA implementation to another, the application should be thoroughly tested with the expectation that some behavioral differences will have to be corrected.

If you use Kodo, be aware of the following:

Using JPA 1.0 APIs

You cannot use any JPA 2 APIs with Kodo. Because Kodo supports only JPA 1, trying to use any JPA 2 APIs will generate an error.

Using persistence-configuration.xml

The Kodo persistence-configuration.xml descriptor is valid only when Kodo is the persistence provider. If you include a persistence-configuration.xml in an application that uses injection and you do not specify Kodo as the persistence provider, the persistence-configuration.xml descriptor is ignored and a warning is issued.

Updating Applications to Overcome Conflicts with JPA 2.0

Kodo is based on open-source OpenJPA 1.x, the JPA 1.0 framework and provider from the Apache Foundation. Although JPA 1.0 is upwardly compatible with JPA 2.0, JPA 2.0 introduced some methods to existing JPA interfaces that conflict with existing signatures in the OpenJPA interfaces used in Kodo. These conflicts arise because the OpenJPA interfaces extend the JPA interfaces that contain the methods that are revised in JPA 2.0.

These conflicts could cause problems with applications that use Kodo as the persistence provider, because the JPA 2.0 jar (rather than the JPA 1.0 jar) is on the WebLogic Server classpath.

To prevent these conflicts, two methods have been changed in the OpenJPA interfaces that ship with Kodo in WebLogic Server 12c and later. The OpenJPA methods that cause the conflict are:

  • public <T> T OpenJPAEntityManager.detach(T pc)

    The above method conflicts with the following JPA 2.0 method in the EntityManager interface:

    public void detach(Object)

  • public Properties OpenJPAEntityManagerFactory.getProperties()

    The above method conflicts with the following JPA 2.0 method in the EntityManagerFactory interface:

    public Map<String, Object> getProperties()

The new signatures are:

  • public <T> T OpenJPAEntityManager.detachCopy(T pc)

  • public Map<String, Object> OpenJPAEntityManagerFactory.getProperties()

  • public Properties OpenJPAEntityManagerFactory.getPropertiesAsProperties()

The first two new signatures follow the changes made in OpenJPA 2.x to address these same conflicts. These signature changes do not alter the semantics of the methods. The getPropertiesAsProperties method is provided as a convenience to application developers who do not want to accept the different return type of the redesigned getProperties method. However, the method getPropertiesAsProperties is not currently in the OpenJPA 2.x interface.

Because of these changes, you should update any applications that use these methods and recompile them with the Kodo OpenJPA 1.0 jar (org.apache.openjpa_n.jar) and the JPA 1 jar (javax.persistence_n.jar) that are shipped with WebLogic Server 12c (or later). This will prevent the old method signatures from being used. After recompiling and deploying, the applications will run without change in behavior.

Applications that use Kodo/JDO are not affected by the conflicts described above. Therefore, you do not have to modify or recompile them.

Using a Newer Version of OpenJPA in Oracle WebLogic Server

The current release of OpenJPA from the Apache Foundation supports JPA 2, and you can use it as the persistence provider for applications deployed to WebLogic Server.

Note:

OpenJPA is a third-party library that you must plug into WebLogic Server. As such, Oracle support for Oracle WebLogic Server does not include support for the use of OpenJPA. These instructions are provided as a courtesy.

To use the newer version of OpenJPA, do the following:

Note:

This last step applies for any JPA implementation that is packaged with an application. You must specify the implementation to use in the application code and not just accept the default set in WebLogic Server.