Migrating fromIBM VisualAgeto JBuilder 5by Hartwig Gunzer, Sales Engineer, Borland®

Preface

IntroductionThe intention of this paper is to show how to migrate existing

projects from IBM® VisualAge™ for Java™, version 3.5 to

Borland® JBuilder 5. Therefore, various types of applications

are discussed. We start with simple GUI applications that have

been developed in VisualAge, then we move on to database

applications that have bean generated by a smart guide using

Data Access Beans. Enterprise applications are addressed in the

final two chapters, where we show how to migrate Enterprise

JavaBeans™ (EJB™) from VisualAge to JBuilder and how to

create test clients within JBuilder. After migration, the EJB will

run in Borland AppServer™ 4.5 that is shipped with JBuilder 5

Enterprise. Finally, we will use session beans to demonstrate

deployment to IBM WebSphere 3.5.

AudienceEvaluators of JBuilder 5 and Borland AppServer 4.5 who are also

evaluating VisualAge might find this paper useful for comparing

concepts between the two IDEs.

However, since a thorough knowledge of the Java programming

language is needed to understand the steps for migrating the

projects, this paper for the most part is targeted toward Java

developers.

ContentsPreface 1

General differences 2

Migrating GUI applications 2

Migrating applets 8

Migrating database applications 8

Migrating EJB – session beans 13

Deploying to WebSphere 18

Migrating EJB – entity beans 19

JBuilder™

2

General differences between VisualAgeand JBuilder

VisualAge maintains a repository to store all projects. Thus, no

file is visible on the hard disk until it is exported from the

repository. Files existing on the hard disk must be imported into

the repository prior to being used in VisualAge. In contrast,

JBuilder stores projects and associated files on the file system;

there is no need for exporting project files.

Migrating GUI applications

Concepts of VisualAgeClasses that extend java.awt.Component, such as a frame or an

applet, can be modified visually in the VisualAge Visual

Composition Editor. Usually GUI applications are developed

this way. For the event handling, the editor lets you chose either

a single inner class for the entire event handling code or one

single inner class for each event that is to be processed.

We continue by assuming that one inner class for the entire

event handling has been chosen.

The reference to the inner class is stored in an attribute called

ivjEventHandler; the inner class itself is called IvjEventHandler.

The inner class reference is registered with the components as a

listener. This registration takes place in a method called

initConnections(). Thus, the inner class implements all the

necessary interfaces. Inside each of the implementations, there is

a method of the outer class named connEToC1(…),

connEToC2(…), and so on. These methods contain the event

handling code. Depending on the kind of connection that has

been used in the Visual Composition Editor, they might be

named in slightly different ways, such as:

• connEtoCxxx()

- For Event-To-Code connections

• connEtoMxxx()

- For Event-To-Method connections

• conPtoPxxx()

- For PropertyToProperty connections

The default constructor of the GUI class calls super() explicitly

and afterwards a method called initialize(). This method contains

all the initialization routines, including a call to initConnections().

VisualAge uses lazy initialization for the sub-components, that is,

components like buttons or text fields are not initialized until

they are needed for the first time. Therefore, appropriate

methods like getButton1(), getTextField1() are provided. The default

name of the sub-components contains the prefix ivj followed by

the components’ names, e.g. ivjButton1. The following drawing

shows the dependencies between the methods and attributes for

one button:

Dependencies in VisualAge

Concepts of JBuilderJBuilder features a designer that lets you construct classes

visually. In order to keep the designer and the source code in

sync, a private method called jbInit() is used. This method gets

parsed each time the view is switched to the designer tab.

constructor

initialize()

initConnections()

getButton1() ivjEventHandler

connEToC2()

button1_ActionPerformed()

JBuilder™

3

Without the jbInit() method, the appearance of the application

would not be visible within the designer.

In contrast to VisualAge, JBuilder uses both anonymous and

standard adapter classes. No inner classes are used. The code

style can be changed in the project properties.

There is one adapter class for each sub-component. These

adapter classes call a method of the GUI class that handles the

event delegated by the sub-component. The default name starts

with the name of the attribute that holds the reference to the

sub-component, followed by an underscore and the name of the

event-handling method as specified in the appropriate interface.

This is the place where you usually put in your event-handling

code. The picture below illustrates the dependencies in JBuilder.

dependencies in JBuilder

Dependencies in JBuilder

Important notes about the designerThis section discusses important rules by which the JBuilder

designer parses and generates source code:

The JBuilder designer accepts only property settings as defined

in the JavaBeans specification. That means that any setter

method for a property must take one parameter only. Any other

kind of method calls—that is, calls that take multiple

parameters—will be changed when they are modified. A typical

example in VisualAge is the method initialize() calling setSize()

with multiple parameters.

Setting the form’s size in VisualAge

The JBuilder designer recognizes the multiple parameters and

will change the method call the next time the property is

modified to look like the example below:

Changes the call done by the designer

The Visual Composition Editor of VisualAge often creates

panes with a null layout. As a result, the initialization routines for

the child components contain calls to setBounds or setLocation

taking multiple parameters. But, as we have seen, this is no

problem for JBuilder.

Steps for migrationNext, we examine the steps necessary for migrating GUI

applications from VisualAge to JBuilder.

constructor

jbInit()

register adapter class

ivjButton1_actionPerformed()

private void initialize() {

...

setSize(640, 480);

...

}

private void initialize() {

...

setSize( new Dimension (640, 480) ); ...

}

JBuilder™

4

The Approach The following approach tries to reuse as much code as possible.

It might appear that calling the method button1_ActionPerformed()

directly within the adapter class is a better solution. However, in

VisualAge the connEToCx() methods, as well as the

initConnections() methods, may contain user code next to the code

that has been generated. If the methods contain user code, they

must not be removed. So the approach shown below is the

preferred one. We will add the necessary methods generated by

VisualAge and call them from methods needed by JBuilder.

The calls to the event handlers will be put into adapter classes so

that the inner classes are no longer needed.

Dependencies in JBuilder after migration

The necessary stepsWe will show all the steps necessary for migration by applying

them to a small GUI application that has been developed in

VisualAge. The appearance of our application is illustrated

below.

Sample GUI application in VisualAge

Our application consists of exactly one class AWTApp that

extends java.awt.Frame and contains two buttons and two edit

fields. If the user enters a string into the upper text field and

clicks the left button, the string will be converted to upper case

and displayed in the text field at the bottom of the frame.

Clicking on the right button will cause the application to be

terminated.

As shown above, there are three event-handling methods in the

application: button1_ActionPerformed, dispose, and

button2_ActionPerformed.

1) Exporting the project files from the repository ofVisualAge to the file systemBy choosing File|Export in VisualAge, a dialog window will

open with the smart guide, helping us export the application.

First, we must decide where to export the application. In our

case we chose the uppermost radio button specifying that the

project files will be exported to a directory.

constructor

jbInit() register adapter class

ivjButton1_actionPerformed()

connEToC2()

initialize()

getButton1()

initConnections()

button1_ActionPerformed()

JBuilder™

5

Exporting files in VisualAge

Click “Next ” to proceed to the next window. Now you must

enter the directory and specify all of the files that are to be

exported. In our example, we just need to export our application

source file, that is, the .java file.

Exporting to a directory

By clic

compl

2) SetStart b

ProjeThe p

projec

from V

will ad

Setting

Exporting to a directory

king “Finish,” the part concerning VisualAge is

eted, and we move on to the part concerning JBuilder.

ting up the project in JBuildery creating a new project in JBuilder (select File|New

ct)roject wizard opens up where you should change the

t directory to the directory you entered when exporting

isualAge (refer to the previous step). Note that JBuilder

d the src directory, so you do not have to specify it.

the project directories

JBuilder™

6

When you are done, click “Next.” Now you can check the

directory settings.

The project directories

Click “Finish” to create the project. The automatic package

discovery of JBuilder will add all java packages to the project,

which will be found under the src directory. In our case these are

exactly the exported classes from VisualAge.

If you look at the project pane you can see that our package has

been found and has become part of our project.

The JBuilder project pane

JBuilder 5 is able to read and parse code that has been generated

by VisualAge 3.5. But before we can move on to the designer,

we have to make sure that all property settings have been

changed so they can be understood by the designer. Refer to the

section "Important notes about the designer".

By now we are able to see the GUI layout in the designer.

The application in the designer

But we will not see any event handlers in the property inspector.

So, the next step is to make the event handlers known to

JBuilder. Therefore let’s take a look at the inner class

IvjEventHandler.

class IvjEventHandler implements

java.awt.event.ActionListener,

java.awt.event.WindowListener

{

public void actionPerformed(java.awt.event.ActionEvent e)

{

if (e.getSource() == AWTApp.this.getButton1())

connEtoC2(e); if (e.getSource() == AWTApp.this.getButton2())

connEtoC3(e); };

public void windowActivated(java.awt.event.WindowEvent e) {};

public void windowClosed(java.awt.event.WindowEvent e) {};

The inner class IvjEventHandler, part 1

JBuilder™

Since this is the action performed handler for button1, enter

connEtoC2() in the newly generated method.

public void windowClosing(java.awt.event.WindowEvent e) {

if (e.getSource() == AWTApp.this)

connEtoC1(e); };

public void windowDeactivated(java.awt.event.WindowEvent e) {};

public void windowDeiconified(java.awt.event.WindowEvent e) {};

public void windowIconified(java.awt.event.WindowEvent e) {};

public void windowOpened(java.awt.event.WindowEvent e) {};

};

7

The inner class IvjEventHandler, part 2

By examining the if-statements, we see that the event handling

routine for Button1 is connEToC2(), for Button2 it is

connEToC3(), and for the windowClosing event of our

application, it is connEToC1() . Since JBuilder does not use inner

classes we have to provide adapter classes.

Switch to the designer, click on the button with the

“toUpperCase” label, and select the “Event” tab in the property

inspector.

We let JBuilder generate an event handler for the action

performed event by double-clicking the appropriate text field.

Generating an action performed event handler

N

w

f

N

t

s

4A

I

h

“

void ivjButton1_actionPerformed(ActionEvent e) {

connEtoC2(e); }

The complete event handler for button1

ext, we repeat the last steps for the other button and the

indowClosing event of our application so that we get the

ollowing event handling code within our application class:

void ivjButton1_actionPerformed(ActionEvent e) {

connEtoC2(e); }

void ivjButton2_actionPerformed(ActionEvent e) {

connEtoC3(e); }

void this_windowClosing(WindowEvent e) {

connEtoC1(e); }

The complete event handling code

ow that we have our own event handling code in JBuilder,

here is no need for the inner class anymore, and it is time for

ome clean up.

) Removing source code that is no longer neededs mentioned before, you can remove the inner class

vjEventHandler as well as the attribute of the outer class that

olds a reference to it. This attribute is called

ivjEventHandler”.

JBuilder™

8

In the next step, we remove the code from initConnections(),

where the registration of ivjEventHandler at the sub-

components take place. In our case, the method will contain an

empty body afterwards, so we might choose to remove the

whole method. But keep in mind that we would have to remove

the call to initConnections() from within the method initialize() as

well.

These three lines of code are no longer needed

Compile and run your application, checking to see that

everything works properly.

5) Working on the project within JBuilderNow, the migration is complete, and we can work on the project

in the way we are accustomed. JBuilder will put all the code that

has to be generated in the correct places, as the following

example shows. If we want to change the background color of

the left button as well as its foreground color, then we set the

properties in the property inspector as show below.

Changing the color properties of the left button

The generated code is not put into the method jbInit(), as you

might expect, but into the method getButton1(). This is correct

since all the setting of the properties for this button take place in

this method.

N

in

private void initConnections() throws java.lang.Exception {

// user code begin {1}

// user code end

this.addWindowListener(ivjEventHandler); getButton1().addActionListener(ivjEventHandler); getButton2().addActionListener(ivjEventHandler);}

private java.awt.Button getButton1() {

if (ivjButton1 == null) {

try {

ivjButton1 = new java.awt.Button();

ivjButton1.setName("Button1");

ivjButton1.addActionListener(new

AWTApp_ivjButton1_actionAdapter(this));

ivjButton1.setBackground(Color.orange); ivjButton1.setForeground(Color.red); ivjButton1.setLabel("toUpperCase");

// user code begin {1}

// user code end

} catch (java.lang.Throwable ivjExc) { … };

}

The method getButton1() after migration

ote also that the registration of the adapter class has been put

to this method.

JBuilder™

9

Migrating appletsThe steps needed for migrating applets from VisualAge to

JBuilder are much the same as before. The only difference is that

we have all our initialization code within the method init().

Migrating database applicationsNow let’s look at the different concepts of the two IDEs with

respect to database applications. We show only the classes with

which a developer works directly when creating a typical

database application. For the underlying architecture, please refer

to the help pages of the IDEs.

Concepts of VisualAgeDatabase applications that have been created by the smart guide

of VisualAge usually consist of two different kinds of classes:

classes that are used to display the data received from the

database and classes that are responsible for the database access

itself. The access classes extend the class DatabaseAccess that

belongs to a library of VisualAge called Data Access Beans.

These beans are also used internally by the data access class to

communicate with the database. Within this class there are at

least two static methods. One returns a connection to the

database; the other maps to a SQL select statement. There is one

static method for each statement, as illustrated in the figures

below.

Since the view class represents a GUI to the application, the

view class structure resembles the one described in our

discussion about migrating GUI applications.

Concepts of JBuilderDevelopers use the JBuilder DataExpress™ database

functionality to create database applications. In addition,

dbSwing components are provided to create a user interface for

the application. If you use the database access components or

the dbSwing components, they will be placed as attributes within

the view class. So there is no separation in JBuilder, as in

VisualAge. Further, VisualAge, data received from a successful

database connection at design time already will be displayed

within the frame. The following two figures show the class

diagrams of the same application, as generated by VisualAge and

JBuilder, respectively.

Classes generated by the smart guide of VisualAge

JBuilder™

10

Classes generated by JBuilder DataExpress

Resulting steps for migrationThe approachAs you can see, the approaches of the two IDEs are very

different. In order to reuse as much code as possible, we will

change only the view class of the application and retain the calls

to the data access class.

Since there exist almost the same dependencies as in the

previous chapter, the result of this approach will also look

similar. Please refer also to the previous chapter (“Migrating

GUI Applications”).

The necessary stepsThe example we use here is a database application that has been

generated by VisualAge. This application connects to the

InterBase employee database, displaying the rows of the country

table and allowing the user to change the data via a navigation

toolbar, as shown in the diagrams above. There are two classes:

InterbaseApp is the view class, and InterbaseAccess manages all

communication with the database.

Sample database application that has been generated by VisualAge

1) Exporting the project files from the repository ofVisualAge to the file system.In this case, we have to export the two classes of the database

application as well as all the referenced classes, especially the

DataAccess Beans of VisualAge.

We start with the referenced classes and export this time to a jar

file.

Chose File|Export as before.

Select Jar File and click Next.

Exporting to a jar file

JBuilder™

11

Specify the path and the name to the jar file, and click the button

with the label

“Select referenced types and resources.”

Exporting to a jar file

Uncheck the .java checkbox, as we need only the class files.

Unfortunately, VisualAge does not select all the classes we need

to compile the application successfully.

Click the “Details” button next to the .class label.

Specify to export all the DataAccessBeans classes

To keep things simple, select all the DataAccessBeans by clicking the

checkbox.

Uncheck all classes from your project, especially the two classes

the application consists of (click checkbox twice).

Specify to export no classes of the project

Now that we have created a jar file containing all the class files,

we can export the two source code files to a directory.

We select InterbaseApp and InterbaseAccess and export them to

a directory, as discussed in the previous chapter. Now let’s

switch to the JBuilder IDE

2) Setting up the project in JBuilderCreate a new project and set the project directories to point to

the directory to which you exported the .java files.

Now select the tab “Required libraries.” Click the “Add”button, and add the jar file we exported from VisualAge to our

project. You might have to create a new library in order to do so.

Please refer to the JBuilder help pages.

JBuilder™

12

We also have to add the jar file containing the database driver

classes, which means that we have to tell JBuilder where to find

the interclient.jar.

Adding the database driver classes

JBuilder should be able to compile and run the application by

now.

3) Changes in the source codeTo determine which event handlers we have to care about, we

switch to the source code of the GUI class ("InterbaseApp") and

move on to the inner class called IvjEventHandler.

er.

By now you should be able to work on the class in the design

In the next step we make the event handling code known to

JBuilder.

class IvjEventHandler implements java.awt.event.MouseListener,

java.beans.PropertyChangeListener {

public void mouseClicked(java.awt.event.MouseEvent e) {

if (e.getSource() == InterbaseApp.this.getScrollPaneTable())

connPtoP3SetTarget(); };

public void mouseEntered(java.awt.event.MouseEvent e) {};

public void mouseExited(java.awt.event.MouseEvent e) {};

public void mousePressed(java.awt.event.MouseEvent e) {};

public void mouseReleased(java.awt.event.MouseEvent e) {};

public void propertyChange(java.beans.PropertyChangeEvent evt)

{

if (evt.getSource() == InterbaseApp.this.getSelect() &&

(evt.getPropertyName().equals("currentRow")))

connEtoC1(evt); };

The inner class IvjEventHandler

As you can see, there is an event handler for the MouseEvent of

the ScrollPaneTable called connPToP3SetTarget() as well as an

event handler for the property change event of he property

called Select. The handler is called connEtoC1(...). The attribute

that holds the property values is called ivjSelect.

Let JBuilder generate adapter classes for the events, as shown in

the previous chapter, and add the event handling methods.

Afterwards, the class should contain methods that look like this:

The complete event handling code

void ivjSelect_propertyChange(PropertyChangeEvent e) {

if(e.getPropertyName().equals("currentRow")) connEtoC1(e); }

void ivjScrollPaneTable_mouseClicked(MouseEvent e) {

connPtoP3SetTarget(); }

JBuilder™

13

4) Removing source code that is no longer neededRemove the inner class IvjEventHandler as well as the attribute

of the outer class that holds a reference to the inner class. The

attribute is called ivjEventHandler.

Now find the method initConnections:

The method initConnections

Remove the three bold printed lines. The first and the second

register the inner class as an event handler while the third has

been inserted by JBuilder. If you do not remove it, your

application will still compile and run, but you will not see any

data displayed unless you click the “execute” button. So, you

should remove it to get exactly the same behavior as in

VisualAge. Since the method contains some more calls to other

methods, you must not remove the whole method.

Compile and run your application to see how everything works.

Note the message that the code generated by VisualAge contains

calls to methods that are marked as deprecated. Make sure

InterBase Server and InterServer are running before starting the

application. Otherwise, the driver would not be able to

communicate with the database.

The running database application

Migrating EJB: Session BeansIn this chapter, there is no need to examine contrasting concepts

between VisualAge and JBuilder because both IDEs adhere to

the EJB specification (VisualAge supports only the EJB 1.0

specification, but that limitation will not cause problems for us

here).

Steps for migrationWe created a stateless session bean in VisualAge that acts as a

calculator engine providing some basic arithmetical routines.

private void initConnections() throws java.lang.Exception {

// user code begin {1}

// user code end

getSelect().addPropertyChangeListener(ivjEventHandler); getScrollPaneTable().addMouseListener(ivjEventHandler); connPtoP1SetTarget();

connPtoP2SetTarget();

connPtoP3SetTarget();

this.getContentPane().add(ivjJFrameContentPane, null); ivjSelect.addPropertyChangeListener(new

java.beans.PropertyChangeListener() {

public void propertyChange(PropertyChangeEvent e) {

ivjSelect_propertyChange(e);

}

});

}

JBuilder™

14

The session bean in VisualAge

The session bean’s remote interface

Export the bean and its two interfaces to a directory and switch

to JBuilder.

Assuming that you have already installed Borland AppServer 4.5

and configured JBuilder to work with it (refer to the help pages,

if necessary), create a new project and set the directories of your

project to point to the exported classes.

Setting up the project

package ejbtest;

/**

* This is an Enterprise Java Bean Remote Interface

*/

public interface EJBCalculator extends javax.ejb.EJBObject {

int add( int arg1, int arg2) throws

java.rmi.RemoteException;

int sub( int arg1, int arg2) throws

java.rmi.RemoteException;

int div( int arg1, int arg2) throws

java.rmi.RemoteException;

int mult( int arg1, int arg2) throws

java.rmi.RemoteException;

int mod( int arg1, int arg2) throws

java.rmi.RemoteException;

}

Setting up the project, part 2

Add an empty EJB group to the project by selecting

“File|New|Enterprise|Empty EJB Group,” as shown

below.

Creating an empty EJB group

JBuilder™

Creating an empty EJB group

In order to deploy the bean to the Borland AppServer (BAS), we

have to specify a deployment descriptor. We can use the JBuilder

deployment descriptor editor.

Select the ejbgroup project window and right-click the EJB

deployment descriptor in the navigator window. Select “NewSession Bean.”

Specifying the deployment descriptor

Before we can compile our code, we have to tell JBuilder that

IIOP classes have to be generated for the home interface. Right-

click the home interface in the project window, and select “Properties” and the “Build” tab. Check “Generate IIOP.”

15

Creating the deployment descriptor for a new session bean

Enter a name for the bean and click “OK.” The “Main” tab will

be displayed. Specify full qualifying names, that is, the package

name and the class name, in the text fields.

Setting properties of the home interface

JBuilder™

Cl

inf

Yo

V

No

co

de

Be

ru

ca

Select “Tools|EJB Deployment.” The deployment wizard

opens and guides us through five steps:

Let JBuilder generate IIOP for the home interface

ick the button “Verify” to check whether you provided all the

ormation needed to deploy the bean to BAS.

u should get the following result.

The deployment wizard, step 1 of 5

Since we have only one jar file, nothing more is required. Click

"Next" and "Next" again to skip the second step.

In step three, the jar file will be checked and compiled again.

You should get the result shown below:

16

erifying the deployment descriptor

w build the whole project. This will also create a jar file

ntaining our session bean and all the necessary files needed for

ployment.

fore deploying the session bean, make sure that BAS is up and

nning. Otherwise, JBuilder will not find a container to which it

n deploy.

Deploying an EJB to BAS, step 3 of 5

Click "Next" to proceed. To specify an EJB container, to which

we can deploy, click "Add EJB Container." You should find

the container of the EJB server you started: in our case the

server is called EJBServer1.

JBuilder™

If you start the Borland AppServer Console and switch to the

.

Deploy

Click

Deploy

contents of the EJB container, you can see the results of the

successful deployment as well:

ing an EJB to BAS, step 4 of 5

"Next" and watch the bean being deployed to BAS:

The Borland AppServer Console

The migration of the session bean is now complete. To see the

session bean at work, we next want to create a testclient in

JBuilder.

Creating a test client in JBuilderSelect “File|New” and “Application” on the tab “New.”Enter all the information the wizard requires, and click

17

ing an EJB to BAS, final step

“o

o

b

T

Finish.” Switch to the design tab and create the user interface

f a calculator with two text fields for entering the arguments—

ne text field for displaying the result of the calculation and five

uttons for the different calculations our session bean provides.

hen select “Wizards|Use EJB Test Client.”

JBuilder™

Creating a test client.

Click "Next," "Next," and "Finish."Your frame class now contains an attribute holding a reference

to the test client. This test client provides easy access to the

session bean.

Now we must specify the event handling code. Provide an

ActionEvent handler for each button and enter the code as

shown below.

Each button calls the appropriate method of the bean. For

example, the button containing the label “+” calls “add.”

Now run the Test Client the same way, that is, select the client

application and select “Run” from the context menu.

You should see in the message pane that JBuilder has

successfully initialized the bean.

The JBuilder message pane

Test the application and do some calculations. Note that every

time you click a button, you talk to the session bean.

The running test application

Deploying to WebSphereThe development of EJBs in JBuilder does not depend on the

application server to which you will deploy. If you have used

void jButton4_actionPerformed(ActionEvent e) {

eJBCalculatorTestClient1.create(); int arg1 = Integer.parseInt(jTextField1.getText());

int arg2 = Integer.parseInt(jTextField2.getText());

int result =

eJBCalculatorTestClient1.add(arg1, arg2); jTextField3.setText(String.valueOf(result));

}

18

Calling methods of the generated test client

Start the container by selecting the EJB group and selecting

“Run” from the context menu that pops up when you right-

click the mouse.

VisualAg

the appli

same as

-- Initializing bean access.

-- Succeeded initializing bean access.

-- Execution time: 1280 ms.

e and WebSphere before, there is no need to change

cation server. The required steps will be almost the

when deploying to Borland AppServer.

JBuilder™

The setupSwitch to the enterprise setup page in Tools|EnterpriseSetup|Application Server| WebSphere 3.5, and specify the

needed installation directories. Note that you don't have to use

DB2® as the administrative database. For instance, if you leave

the "DB2 Installation Directory" field blank, JBuilder will use

InstantDB™ by default. The trial version of WebSphere uses

InstantDB as the administrative database, so you will be able to

use the trial versions as well. Once you have entered all the

information, make sure that the changes will be applied to the

current project by clicking on the checkbox. Click "OK" to

finish the setup.

T

C

s

w

S

o

19

he enterprise setup page for WebSphere

heck your project properties if they show the same settings:

ettings made in the enterprise setup page are global settings,

hereas the settings of your project might be different.

elect “Tools|EJB Deployment.” The deployment wizard

pens up once more, but this time it looks different.

The

depl

shou

The W

Thes

Web

exam

Deploying to WebSphere

JBuilder message pane shows you the result of the

oyment. If you switch to the WebSphere console, you

ld be able to see the EJB by now:

ebSphere console showing the deployed session bean

e few changes must to be done in order to deploy to

Sphere. The other steps, creating a test client in JBuilder, for

ple, are the same as before.

JBuilder™

Migrating EJB: Entity BeansThis section discusses the migration of an entity bean with

container managed persistence (CMP) that has been generated in

VisualAge. In this part, we use JDataStore,™ a DBMS, written

entirely in Java, which is included with JBuilder Enterprise

The bean represents a mapping to the country table that is part

of the JDataStore employee database.

There are two attributes: country, which also acts as the primary

key, and currency.

Steps for migrationAgain, start with exporting the files from VisualAge.

Export all the files the bean consists of to a directory. For the

entity bean we present, we have to export five source code files:

the bean class, the home and the remote interface, a finder class,

and a key class. To keep things simple, all the files in this

example start with the name “EJBCountry” (shown further

below in the JBuilder project window and in the deployment

descriptor).

In addition, we export all referenced classes to a jar file. There

are only two classes we need. They are both called "Link," but

they belong to different packages.

Exporting the referenced classes

Create a new project in JBuilder. Add the source path of the five

classes as shown in the previous examples. The required libraries

this time are 4.5 library and the jar file containing the referenced

classes from VisualAge.

20

Exporting the referenced classes

T

(

The three required libraries

ell JBuilder to generate IIOP for the home interface.

EJBCountryHome.java ).

JBuilder™

Create an empty EJB group and add a new entity bean to the

deployment descriptor in the navigator window.

Specify all the classes needed with full qualifying names.

the connection by clicking the appropriate button.

The deployment descriptor for the entity bean

Now we tell the container about the mapping to the employee

database. Add a new datasource to the deployment descriptor by

right clicking datasource in the navigator window.

Spec

JDa

The datasource for the entity bean

Now add the datasource we just specified as a resource to our

entity bean

Creating a resource reference

21

Creating a new datasource

ify URL, driver class, user, and password. We use the

taStore driver to connect to a database called employee.jds. Test

S

c

E

C

l

witch to the “Persistence” tab. Here we will specify to which

olumns the attributes of our entity bean will map.

nter the table to which the entity bean maps (Country).

lick the Button “Get Meta Data,” and JBuilder will provide a

ist box displaying all the available columns in this table.

Mapping class attributes to table columns

JBuilder™

Now all the necessary parts of the deployment descriptor have

been specified. Verify it to check for errors.

When you compile the project you will get the following error

message:

Compiler error message

JBuilder tells us that according to the EJB 1.1 Specification we

have to provide a different return type, that is, the primary key

class, so we change the source code accordingly in

EJBCountryBean.java

The entity bean has been deployed to BAS 4.5

If you switch to the Borland AppServer Console you will see the

deployed entity bean next to the session bean we deployed in the

previous chapter.

"EJBCountryGroup.ejbgrp": Entity Bean: "EJBCountryBean"

Invalid bean method return type: expected:entitybean.EJBCountryKeyactual: void in method:

public void entitybean.EJBCountryBean

.ejbCreate(java.lang.String)

throws java.rmi.RemoteException,javax.ejb.CreateException

public EJBCountryKey ejbCreate(java.lang.String argCountry)

throws javax.ejb.CreateException,

java.rmi.RemoteException {

_initLinks();

// All CMP fields should be initialized here.

country = argCountry;

currency = "";

return new EJBCountryKey(country);

22

The ejbCreate method has to return an instance of the key class

When you rebuild your project you should not receive more

error messages. Deploy the entity bean to the BAS as shown in

the previous chapter. The successful deployment should like the

figure below:

As

tes

ge

sec

ho

}

The Borland AppServer Console showing the two deployed EJB

before, we want to create a test application using the JBuilder

t client tool. Accordingly, we have to repeat the steps for

nerating an EJB Test Client as discussed in the previous

tion. We don't want to create a GUI application this time,

wever. Instead, we generate a main method and enter the two

JBuilder™

lines below to get a row of data from the country table. Then

we’ll want to get the contents of the column named "Currency."

Th

Now you may start the test client application in JBuilder. You

should see the following results:

100 E nSco t t s www .bo

public static void main(String[] args) {

…

client.findByPrimaryKey("USA"); client.getCurrency(); }

23

e test client’s main method

Th

t e rp r i se WayVa l l ey , C A 95 066 -324 9r la nd .co m | 831 -43 1 -1000

-- Initializing bean access.

-- Succeeded initializing bean access.

-- Execution time: 6239 ms.

-- Calling findByPrimaryKey(ejbtest.entity.EJBEntityK ...

-- Succeeded: findByPrimaryKey(ejbtest.entity.EJBEnti ...

-- Execution time: 521 ms.

-- Return value from findByPrimaryKey(ejbtest.entity. ...

-- Calling getCurrency()

-- Succeeded: getCurrency()

-- Execution time: 100 ms.

-- Return value from getCurrency(): Dollar.

e entity bean at work

Made in Borland® Copyright © 2001 Borland Software Corporation. All rights reserved. AllBorland brand and product names are trademarks or registered trademarks of Borland SoftwareCorporation in the United States and other countries. Java and all Java-based marks aretrademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.All other marks are the property of their respective owners. 12258