|
|
This chapter provides an overview of developing, deploying, and configuring a BEA Kodo application using WebLogic Server: The following topics are covered:
BEA Kodo an implementation of Sun Microsystem’s Java Persistence API (JPA) specification and Java Data Objects (JDO) specification for transparent data objects. BEA Kodo is available as a stand-alone product and is integrated within WebLogic Server.
This chapter describes how to implement an application using JPA or JDO in WebLogic Server. Within WebLogic Server, the JPA and JDO implementations are part of WebLogic Servers overall Enterprise Java Bean 3.0 persistence implementation.
For general information on creating an application using JPA and JDO, see the Kodo Developer’s Guide.
The first step in implementing a BEA Kodo application on WebLogic Server is to write your application’s code. The following resources provide general information on writing an application that uses BEA Kodo to manage persistence of your data:
Once you are familiar with the steps involved in creating applications using BEA Kodo and have created your application, the following sections describe how to deploy and configure your application using WebLogic Server
If you choose to use a different version of Kodo than the one provided by default within WebLogic Server, you must use the FilteringClassLoader to exclude the Kodo and OpenJPA libraries from the component classpath.
The following example shows how to exclude these class libraries using weblogic-application.xml:
<prefer-application-packages>
<package-name>org.apache.openjpa.*</package-name>
<package-name>kodo.*</package-name>
</prefer-application-packages>
For more information on filtering classloaders, see <xref: http://e-docs.bea.com/wls/docs92/programming/classloading.html>
BEA Kodo contains two separate XML files that contain configuration properties. These files are:
- Need to discuss the relationship between persistence.xml and persistence-configuration.xml
- persistence-configuration.xml is not required
- WLS creates reasonable defaults for all elements of p-c.xml.
Because Kodo is a highly customizable environment, many configuration properties relate to the creation and configuration of system plugins. Plugin properties have a syntax very similar to that of Java annotations. They allow you to specify both what class to use for the plugin and how to configure the public fields or bean properties of the instantiated plugin instance.
Essentially, plugins are defined via a series of properties using name/value pairs. The following example shows how a plugin is defined within persistence.xml
<property name=’myplugin.DataCache’ value=’com.bea.MyDataCache(CacheSize=1000, RemoteHost=’CacheServer)’>
Once you have completed the following tasks:
you are read to deploy your application on WebLogic Server. Once your application is configured, a Kodo application is deployed just like any other application. For complete information on deploying applications, see <xref to deployment>.
Once you have deployed your Kodo application, you can alter the configuration paramters defined in persistence.xml and persistence-configuration.xml.The following topics are covered:
Many Kodo configuration parameters can be configured from the WebLogic Server Administration Console.
If your deployed application has defined a persistence unit within persistence.xml, you can access configuration from within the Administration Console using the following:
From here, you can access all of the Kodo persistence parameters that can be edited from the Administration Console.
| Note: | You cannot create a new persistence unit from the Administration Console. To create a new persistence unit, you must edit persistence.xml manually. |
|