Michael Sikora on Java EE

Converting to Weblogic 10.3 - Part 2

In this blog I describe converting Chapter 3 of my book from glassfish to weblogic 10.3. Chapter 3 deals with persistence. I was expecting difficulties here as glassfish uses Derby as the default embedded relational database and Toplink as the default persistence engine. Weblogic on the other hand uses Pointbase as the default embedded relational database and Kodo as the default persistence engine. However the conversion proved to be quite painless.

I first invoked the Pointbase console from the command line:

C:\beahome\wlserver_10.3\common\eval\pointbase\tools\startPointBaseConsole.cmd

Pointbase is preconfigured with a database administrator PBSYSADMIN with password PBSYSADMIN. PBSYSADMIN has access to all objects in pointbase. I then logged in to Pointbase as PBSYSADMIN. I then created a user, ejbexamples, with password ejbexamples. I then created an ejbexamples schema in the pointbase console.

Next I created a new persistence.xml file to reflect that Kodo is the persistence engine:

<persistence-unit name="BankService" transaction-type="JTA">

<properties>

<property name="kodo.ConnectionURL" value="jdbc:pointbase:server://localhost:9092/demo"/>

<property name="kodo.ConnectionDriverName" value="com.pointbase.jdbc.jdbcUniversalDriver"/>

<property name="kodo.ConnectionUserName" value="ejbexamples"/>

<property name="kodo.ConnectionPassword" value="ejbexamples"/>

<property name="kodo.jdbc.Schema" value="ejbexamples"/>

<property name="kodo.jdbc.SynchronizeMappings" value="buildSchema"/>

</properties>

</persistence-unit>

That's it. The examples populate the CUSTOMER table which can be examined from the Pointbase console. I'll try to cover more than one chapter in my next blog.

Converting to Weblogic 10.3 - Part 1

In this blog I'll describe my experience converting the examples in Chapter 2 of my book from glassfish to weblogic 10.3. The glassfish examples use an ant build script for compiling, packaging and deploying rather than an IDE such as Netbeans. Weblogic has its own IDE, Workshop, but many weblogic developers use Eclipse as their IDE. With Oracle acquiring weblogic, JDeveloper is also likely to be a candidate IDE. I avoided choosing an IDE by converting the glassfish ant build scripts to run on weblogic. The conversion took the following steps:

(1) set weblogic environment variables in the env.properties file

(2) in build.xml file modify classpath to use weblogic jar files such as javax.ejb_3.0.jar and javax.annotation_1.0.jar

(3) in build.xml replace the glassfish asadmin tool for deployment with the weblogic wldeploy Ant task.

The glassfish examples for the most part used a Java application client to invoke an EJB. The client runs in an application client container- this means you can use dependency injection rather than JNDI to invoke the EJB. However weblogic does not provide an application client container. The EJB specification provides for an application client container as an option and not as a mandatory requirement. Oracle's existing EJB3 container, OC4J, does provide an application client container. The next release of weblogic is supposed to incorporate some OC4J features: hopefully an application client container will be one of these.

This means I have to use JNDI and make a few source code changes. I need to modify the session bean as follows:

@Stateless(mappedName="Time")

public class TimeServiceBean implements TimeService {

In the client I need to add the following JNDI code:

InitialContext ctx = new InitialContext();

TimeService timeService = (TimeService) ctx.lookup("Time#ejb30.session.TimeService");

The format of the lookup argument is quite different from the glassfish, OC4J and JBoss conventions. I couldn't find the format description in the weblogic documentation. I had to google around a bit to find this out.

Another difference I encountered was in lab5 where passivation of stateful session beans is demonstrated. In glassfish I was able to set the maximum_beans_in_cache and idle_timeout values in the administrator console. This is not possible in weblogic: these values need to be set in the weblogic-ejb-jar.xml deployment descriptor and only apply to the bean being deployed.

Another gotcha I encountered was in using the correct client runtime library. In lab1 a client invokes a stateless session bean which returns the current time. In this example I used the thin-client wlclient.jar runtime library. However for the stateful session bean example in lab4 I needed to use the full-client wlfullclient.jar runtime library. The documentation does not make it entirely clear in which circumstances a full-client rather than thin-client runtime library is required.

In the next blog I'll cover the conversion of Chapter 3 which deals mostly with persistence.

EJB 3 Developer Guide

Welcome to my inaugural blog. In this blog I will be writing about Enterprise Java with a particular focus on version 3 of Enterprise JavaBeans (EJB 3) and the Java Persistence API (JPA). I am a Sun certified Enterprise Architect and have been working in the J2EE/Java EE field since 2001. Before that I had experience in database and datawarehousing.

I am the author of "EJB 3 Developer Guide" published by PACKT. Although this is short concise book (260 pages) , there are nearly 50 worked examples which can be downloaded. The book and worked examples are based on Sun's Glassfish Application Server and embedded Toplink persistence engine. These were chosen as Glassfish is the reference EJB 3 container and Toplink the reference persistence engine. The book is available at

www.packtpub.com/developer-guide-for-ejb3/book

Since the book was published at the end of May 2008 Oracle's purchase of BEA has been finalized. BEAs flagship product was the Weblogic Java EE application server. This will now replace Oracles own Java EE application server, OC4J, although some features of OC4J will be incorporated into future releases of Weblogic.

As Weblogic is one of the leading commercial Java EE application servers, over the next few weeks I will be converting the worked examples from my book to run on Weblogic. Of course as Java is 'Write once, run everywhere’ I do not expect to make any source code changes. However configuration and deployment aspects will be different.

So watch this space to see how I get on.