Sahoo's Blog: May 2006 Archive

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 glassfish persistence

Which GlassFish build to use?

Posted by ss141213 on May 05, 2006 at 01:45 AM | Permalink | Comments (3)

Looking at some of the recent postings in the GlassFish forum, there appears to be some confusion in the GlassFish user community about which build to use. I will try to address the issue in this blog.

The main reason for this confusion is due to presence of two very active branches in the GlassFish CVS repository, viz: SJSAS90_FCS_BRANCH and the trunk (a.k.a. the main branch). They look something like this:



                         

                                   b48

                                  /

                                 b47

                                /

                               b46

                              /

                             b45

                            /

                           b44

                          /

                         b43

                        /

                       /SJSAS_90FCS_BRANCH

                      /

                     /             

TRUNK__..._b41_b42__/____________________ TRUNK

                    ^

                    |

               30 Mar 2006

(The numbers starting with b are build numbers)

As the name suggests, SJSAS90_FCS_BRANCH is used for release of Sun Java System/Application Server PE 9.0 as well as Java EE 5 SDK. As the diagram shows, this branch was forked from the trunk around 30 March 2006. It is a highly controlled branch as it is used to release a product and currently this branch is in high resistance mode as the final release date is fast approaching. As a standard product release process, not all kinds of bug fixes are going into this branch.

The situation is very different for the trunk. It is open for checkins. In fact a lot of bug fixes and quite a few enhancements have gone into the trunk since SJSAS_90FCS_BRANCH was forked. If I have to single out any one module which has changed most in the trunk since the 9.0 branch was forked, then it will be entity-persistence module, which is the Java Persistence API implementation module in GlassFish. Not all these fixes were back ported to the SJSAS_90FCS_BRANCH for obvious reasons. Be rest assured, a number of these bugs will eventually be made available in a subsequent Update Release(UR) for 9.0.

Difference between promoted builds and nightly build
As the name suggests, nightly build happens every night. Before a binary is posted in the nightly download site, it must pass a predefined set of test cases. So, you can use a nightly build during development phase of your project. Typically after a series of nightly builds, one of the nihgtly builds get promoted and is made available in the promoted builds' web site. The typical frequency has been 1 week in GlassFish project. This allows the delta between two promotions to be significant. The number of tests that are run before promoting a nightly build is much larger than what are run to test the nightly builds.

Build Numbers/Name:
Each promoted build has a unique name. e.g. b01, b02...,b48 are all names of promoted builds happening on different dates. The nightly builds also have a name. It has two components viz: the next promoted build number and the date on which it was built. e.g. glassfish-installer-b43-nightly-01_may_2006.jar.

What is the confusion?
If you look at the branch diagram, you shall see that the b41, b42 etc. were built using source from the trunk. After the FCS branch was forked, promoted builds like b43, b44, ..., b48 (this is the latest promoted build as I am writing this blog) were done using source code taken from SJSAS_90FCS_BRANCH. This has confused many users. When users see some bug being marked as fixed, it is natural for them to expect the fix to be available in the next promoted build, but that did not happen after b42. I feel it would have been better to call 9.0 branch builds as something like b43_90 and continue to use b43, b44 as build numbers for trunk builds.
To specifically address such confusion, IssueTracker has a field called target milestone, but at this point, it is not clear what should be used in this field when a fix is integrated into the trunk. I wish, we could just use 9.1.

Finally, there is no promoted builds happening on the trunk right now. If you look at the GlassFish promited builds download site, you can see that after b42, there are no promotions happening on the trunk. Only nightly builds are happening as GlassFish nightly build download site shows. If you choose the platform of your choice there, you can see that there are download bundles are available with names like glassfish-installer-b43-nightly-01_may_2006.jar. Look at the date encoded in the name. That conveys the date on which that binary was built.

When is situation going to improve?
Recently a P1 issue (#640) has been filed and very soon I am hoping to see promoted builds happening on trunk.

Conclusion
In the mean while, if you are waiting for a build which fixes one of the bugs you are encountering, then you may use the latest nightly build. Use the date to decide which one is the latest build, don't assume that since the name contains b43, it is an old build.

Powered by
Movable Type 3.01D

java.net RSS Feeds