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:
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:
Java Persistence 2.0 (JPA 2.0).
JPA 2.0 is part of Java Platform, Enterprise Edition 6 (Java EE 6). It includes improvements and enhancements to domain modeling, object/relational mapping,
Query interfaces, and the Java Persistence Query Language (JPQL). It includes an API for criteria queries, a metamodel API, and support for validation.
For the JPA 2.0 Specification, see "JSR-000317 Java Persistence 2.0" at
Java Architecture for XML Binding (JAXB) 2.2. (The EclipseLink JAXB implementation, plus EclipseLink extensions, is called MOXy.)
For the JAXB 2.0 specification, see "JSR-000222 Java Architecture for XML Binding (JAXB) 2.0 " at
EclipseLink also includes Database Web Service (DBWS), which provides access to relational database artifacts by using a Java API for XML Web Services (JAX-WS) 2 Web service.
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
In addition to all of EclipseLink, Oracle TopLink includes:
TopLink Grid, an integration between TopLink and Oracle Coherence that allows TopLink to use Oracle Coherence as a level 2 (L2) cache and persistence layer for entities. For more information, see Oracle Coherence Developer's Guide and Oracle Fusion Middleware Integration Guide for Oracle TopLink with Coherence Grid.
You must have a license for Oracle Coherence to be able to use TopLink Grid.
Logging integration with WebLogic Server.
MBean support in WebLogic Server.
For information about developing, deploying, and configuring Oracle TopLink applications, see the following:
EclipseLink Documentation Center at
EclipseLink examples at
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:
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.
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.
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.
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.
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.
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:
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.
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.
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
public void detach(Object)
public Properties OpenJPAEntityManagerFactory.getProperties()
The above method conflicts with the following JPA 2.0 method in the
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 (
.jar) and the JPA 1 jar (
.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.
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.
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:
Configure a filtering classloader to use the Kodo and OpenJPA classes, as follows:
In a Web application, include the following stanza in the
<container-descriptor> <prefer-application-packages> <package-name>org.apache.openjpa.*</package-name> </prefer-application-packages> </container-descriptor>
In an enterprise application, include the
prefer-application-packages stanza in
For more information about filtering classloaders, see "Using a Filtering Classloader" in Developing Applications for Oracle WebLogic Server.
Include the OpenJPA jar file in the application's
lib directory. For more information about library directories, see "Library Directories" in Developing Applications for Oracle WebLogic Server.
Configure the application to use OpenJPA (Kodo) as the provider. You cannot simply set Kodo as the domain's default provider in WebLogic Server. You must configure it in the application, as described in Specifying the Persistence Provider in an Application.
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.