Skip to main content

Using Kodo as Java Persistence API provider in GlassFish

Posted by ss141213 on May 28, 2006 at 3:44 AM PDT

Earlier we had shown how to plug in Hibernate in GlassFish. Now it's time for Kodo, which is another high performance & popular O/R mapping solution. Recently Kodo 4.0GA was released and it supports Java Persistence API 1.0. So, I thought I shall give a try using it in GlassFish. The instructions are really simple. They do not involve any unreasonable steps.

Step #1: Download and install GlassFish
Install it in any directory of your choice. I refer to that location as GLASSFISH_HOME here. More details about which build of GlassFish to use is given towards the end of this blog.

Step #2: Download and install Kodo 4.0GA
Yes, you should use Kodo 4.0GA or above. Don't use any of the earlier releases (like) 4.0RC1, RC2 etc. as there are issues that have been addressed in 4.0GA. Install Kodo in any directory of your choice. I refer to that location as KODO_HOME here.

Step #3: Install Kodo in GlassFish
I particularly liked the fact that, kodo.jar is a self contained jar file. It does not depend on any other APIs except standard Java EE 5 APIs which are anyway available in GlassFish. So, all we need to do is to make kodo.jar available in GlassFish domain where we want to deploy the application. This can be achieved as follows:

 cp $KODO_HOME/lib/kodo.jar $GLASSFISH_HOME/domains/domain1/lib/ 

GlassFish will automatically make this jar part of its classpath next time when you restart the server.

Step #4: Edit persistence.xml
Make a couple of changes to your persistence.xml. First of all, we need to instruct GlassFish that we want to use Kodo as the persistence provider for this application. This is achieved by setting
element to kodo.persistence.PersistenceProviderImpl. Secondly, we need to provide a valid Kodo license key. This is achieved by setting kodo.LicenseKey. Shown below is a sample persistence.xml:

<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
    <persistence-unit name ="em1">
        <provider>kodo.persistence.PersistenceProviderImpl</provider>
        <properties>
            <property name="kodo.LicenseKey" value="USE YOUR LICENSE KEY"/>
        </properties>
    </persistence-unit>
</persistence>

Step #5: Build and deploy your app
Now you can build your Java EE application and deploy it to GlassFish.
If you want some working applications, then you can download them from my earlier blogs:
a) a web application that uses Java Persistence API -- download the complete sample from here
b) a multi-tier Java EE application (web->ejb->JPA) -- download the complete sample from here.
After downloading, you need to change persistence.xml as described above. Then you can use the existing build.xml to build the app.

Points to note:
1. The choice of persistence provider is a runtime configuration. Development process, environment, source code and build scripts do not depend on the persistence provider. This is evident from the fact that the above examples were written originally for GlassFish and its default provider. We could use it for GlassFish/Kodo combination by just changing persistence.xml.

2. We can use Java2DB feature of GlassFish even while using Kodo. In fact, example #2 uses this. This feature is very handy for folks who don't have a prexisting database schema to work with.

Which GlassFish build to use?
Use latest builds of GlassFish v2. If you want to use GlassFish v1, then you should read the following section as it discusses the two bugs that I discovered while using Kodo in GlassFish v1 (i.e.) SJSAS 9.0pe:

bug #679: This affects web applications using Java Persistence API. As a work around, you have to package enhanced classes in your web application. Kodo comes with a program called kodoc which you can use to enhance the classes. I have already fixed this bug in GlassFish v2 and it will be available in GlassFish v2 build #04. Until build #04 is available, you can download the latest GlassFish v2 nightly build and use.

bug #233: It affects EJBs using Java Persistence API. As a work around, you have to redeploy the application every time you start the server. I have a fix available in my local workspace which I am going to integrate very soon in GlassFish v2 (most likely, it shall be part of v2 build #04).

Conclusion:
Pluggability of third party Java Persistence API providers into a Java EE container offers Java EE users exciting combinations to choose from and that too without sacrificing portability of their applications. Let us know if you are interested in any other provider to be used in GlassFish and we shall give it a try.
More blogs about

Related Topics >>