Migrating from IBM VisualAge to Borland 6 JBuilder

Transcription

1 Migrating from IBM VisualAge to Borland 6 JBuilder by Hartwig Gunzer, Sales Engineer, Borland Table of Contents Preface 1 General differences 2 Migrating GUI applications 2 Migrating applets 8 Migrating database applications 8 Migrating EJB : session beans 13 Deploying to WebSphere 17 Migrating EJB:entity beans 18 Conclusion 21 Preface Introduction The intention of this paper is to show how to migrate existing projects from IBM VisualAge for Java, version 4.0 to Borland JBuilder 6. 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 Enterprise Server 5, which is shipped with JBuilder 6 Enterprise. Finally, we will use session beans to demonstrate deployment to IBM WebSphere 3.5. Audience Evaluators of JBuilder 6 and Borland Enterprise Server 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.

2 General differences between VisualAge and 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 VisualAge Classes 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: constructor initialize() initconnections() getbutton1() ivjeventhandler connetoc2() button1_actionperformed() Dependencies in VisualAge Concepts of JBuilder JBuilder 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. Without the jbinit() method, the appearance of the application would not be visible within the designer. 2

3 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. constructor jbinit() private void initialize() {... setsize(640, 480);... 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: private void initialize() {... setsize( new Dimension (640, 480) );... register adapter class Changes the call done by the designer Dependencies in JBuilder ivjbutton1_actionperformed() 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. Important notes about the designer This 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 the properties are modified. A typical example in VisualAge is the method initialize() calling setsize() with multiple parameters. Steps for migration Next, we examine the steps necessary for migrating GUI applications from VisualAge to JBuilder. 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 3

4 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. constructor getbutton1() Sample GUI application in VisualAge jbinit() initialize() initconnections() register adapter class ivjbutton1_actionperformed() connetoc2() button1_actionperformed() 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. Dependencies in JBuilder after migration The necessary steps We 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. 1) Exporting the project files from the repository of VisualAge to the file system By 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. 4

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 clicking Finish, the part concerning VisualAge is completed, and we move on to the part concerning JBuilder. 2) Setting up the project in JBuilder Start by creating a new project in JBuilder (select File New Project) The project wizard opens up where you should change the project directory to the directory you entered when exporting from VisualAge( refer to the previous step) Note that JBuilder will add the src directory, so you do not have to specify it. Selecting an export destination Setting the project directory 5

6 When you are done, click Next. Now you can check the directory settings. By now we are able to see the GUI layout in the designer. 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 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) {; JBuilder 6 is able to read and parse code that has been generated by VisualAge 4.0. 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". 6 The inner class IvjEventHandler, part 1

7 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) {; ; Since this is the action performed handler for button1, enter connetoc2() in the newly generated method. void ivjbutton1_actionperformed(actionevent e) { connetoc2(e); The complete event handler for button1 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. Next, we repeat the last steps for the other button and the windowclosing event of our application so that we get the following 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 Now that we have our own event handling code in JBuilder, there is no need for the inner class anymore, and it is time for some clean up. Generating an action performed event handler 7 4) Removing source code that is no longer needed As mentioned before, you can remove the inner class IvjEventHandler as well as the attribute of the outer class that holds a reference to it. This attribute is called ivjeventhandler. In the next step, we remove the code from initconnections(), where the registration of ivjeventhandler at the subcomponents take place. In our case, the method will contain an empty body afterwards, so we might choose to remove the

8 whole method. But keep in mind that we would have to remove the call to initconnections() from within the method initialize() as well. private void initconnections() throws java.lang.exception { // user code begin {1 // user code end this.addwindowlistener(ivjeventhandler); getbutton1().addactionlistener(ivjeventhandler); getbutton2().addactionlistener(ivjeventhandler); 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 JBuilder Now 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. 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 Note also that the registration of the adapter class has been put into this method. Migrating applets The 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(). Changing the color properties of the left button Migrating database applications Now 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. 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. 8

9 Concepts of VisualAge Database 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 JBuilder Developers 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 9 Classes generated by JBuilder DataExpress

10 Resulting steps for migration The approach As 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 steps The 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. 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 Specify the path and the name to the jar file, and click the button with the label Select referenced types and resources. Sample database application that has been generated by VisualAge 1) Exporting the project files from the repository of VisualAge 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. Exporting to a jar file 10

11 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 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 JBuilder Create 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. We also have to add the jar file containing the database driver classes, which means that we have to tell JBuilder where to find interclient.jar. 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). Adding the database driver classes JBuilder should be able to compile and run the application by now. 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. 3) Changes in the source code To 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.. 11

12 class IvjEventHandler implements java.awt.event.mouselistener, By java.beans.propertychangelistener now you should be able to work { on the class in the designer. In public the next void step mouseclicked(java.awt.event.mouseevent we make the event handling code known e) { to JBuilder. 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: void ivjselect_propertychange(propertychangeevent e) { if(e.getpropertyname().equals("currentrow")) connetoc1(e); void ivjscrollpanetable_mouseclicked(mouseevent e) { connptop3settarget(); The complete event handling code 4) Removing source code that is no longer needed Remove 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: 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(getjframecontentpane(), null); ivjselect.addpropertychangelistener(new java.beans.propertychangelistener() { public void propertychange(propertychangeevent e) { ivjselect_propertychange(e); ); 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. 12

13 package ejbtest; The running database application Migrating EJB: Session Beans In 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 migration We created a stateless session bean in VisualAge that acts as a calculator engine providing some basic arithmetical routines. /** * 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; The session bean s remote interface Do not export the bean and its two interfaces yet. JBuilder 6 does not let you specify a deployment descriptor without generating an EJB as well. So we have to do little work around. Assuming that you have already installed Borland Enterprise Server 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 The session bean in VisualAge 13

14 Since VisualAge currently does not support the EJB 2.0 specification, we chose to let JBuilder create an EJB 1.1- compliant EJB module. To deploy the bean to the Borland Enterprise Server, we must specify a deployment descriptor. Therefore, we have to generate an EJB in JBuilder as well. So select File New Enterprise Enterprise Java Bean 1.x Setting up the project Add an empty EJB group to the project by selecting File New Enterprise EJB Module, as shown below. Enter the full qualifying name of the bean class of your EJB, that is, the package name and the class name, as specified in VisualAge. In our case, we also specify that our EJB is a stateless session bean: Creating an empty EJB Module Creating the deployment descriptor for a new session bean Now click Finish. Our module will now contain an EJB. By clicking the bean we may, if desired, edit the deployment descriptor. Creating an empty EJB group 14

15 Select Tools EJB Deployment. The deployment wizard opens and we just have to add the jar file that has just been generated and chose a server partition. In our case we deploy to a Borland Enterprise Server called Elvis and use the standard partition. The deployment descriptor Now export the classes that comprise your enterprise bean to the directory in which the EJB wizard of JBuilder generated the source code, typically the src subdirectory of your project directory. Thus, we overwrite the generated source code with our bean implementation from VisualAge and still have a valid deployment descriptor in our project The deployment wizard Click "ΟΚ ΟΚ" to proceed and watch the bean being deployed to Borland Enterprise Server: Select the EJB module with the right mouse button and click the button Verify to check whether you provided all the information needed to deploy the bean to Borland Enterprise Server. You should see 0 errors and 0 warnings in the message pane. Now rebuild the whole project. This will also create a jar file containing our session bean and all the necessary files needed for deployment. Before deploying the session bean, make sure that Borland Enterprise Server is up and running. Otherwise, JBuilder will not find a container to which it can deploy. Deploying an EJB to Borland Enterprise Server By starting the Borland Enterprise Server console and switching to the contents of the partitions, you can see the bean as a result of the successful deployment as well: 15

16 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 enterprise bean. For example, the button containing the label + calls add. The Borland Enterprise Server console The migration of the session bean is now complete. To see the session bean at work, let s create a test client in JBuilder. Creating a test client in JBuilder Select File New and Application on the tab New. Enter all the information the wizard requires, and click Finish. Switch to the design tab and create the user interface of a calculator with two text fields for entering the arguments and one text field for displaying the result of the calculation. Five buttons will be needed for the different calculations our session bean provides. Then select Wizards EJB Use EJB Test Client. 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)); 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 rightclick the mouse. 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. -- Initializing bean access. -- Succeeded initializing bean access. -- Execution time: 1280 ms. The JBuilder message pane Creating a test client. 16

17 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 WebSphere The development of EJBs in JBuilder does not depend on the application server to which you will deploy. If you have used VisualAge and WebSphere before, there is no need to change the application server. The required steps will be almost the same as when deploying to Borland Enterprise Server. The setup Switch to the enterprise setup page in Tools Enterprise Setup Application Server. As you see, it is possible with JBuilder to deploy to eight different application servers. Chose WebSphere 3.5 and specify the required installation directories. Once you have entered the information, click the checkbox to make sure the changes will be applied to the current project. Click "OK" to finish the setup. The enterprise setup page for WebSphere Check your project properties if they show the same settings: settings made in the enterprise setup page are global settings, whereas the settings of your project might be different. Select Tools EJB Deployment. The deployment wizard opens up once more, but this time it looks different. Deploying to WebSphere 17

18 The JBuilder message pane shows you the result of the deployment. If you switch to the WebSphere console, you should be able to see the EJB by now: your classes in VisualAge. The entity bean we present consists of 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 Country (shown further below in the JBuilder project window and in the deployment descriptor). The WebSphere console showing the deployed session bean Generating an entity bean in JBuilder These few changes must to be done in order to deploy to WebSphere. The other steps, creating a test client in JBuilder, for example, are the same as before. Migrating EJB: Entity Beans This 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. Click Next to check if the settings are correct, then click Finish. Export from VisualAge all the files comprising the bean to the source code directory of your project. Also export all referenced classes to a jar file (we need only two classes; both are called Link, but each belongs to a different package). Steps for migration As shown in the previous section, start with creating a project, an EJB module, and an EJB. Use the exact names you use for 18 Exporting the referenced classes

19 Exporting the referenced classes The deployment descriptor for the entity bean Now switch back to JBuilder and select Project Project Properties Required Libraries. The required libraries this time are the Borland Enterprise Server 5 library and the jar file containing the referenced classes from VisualAge. Now we tell the container about the mapping to the employee database. Add a new datasource to the deployment descriptor by right-clicking data source in the structure pane. Creating a new data source Specify URL, driver class, user, and password. We use the JDataStore driver to connect to a database called employee.jds. Test the connection by clicking the appropriate button. The required libraries The datasource for the entity bean 19

20 Now add the datasource we just specified as a resource to our entity bean When you compile the project you will get the following error message: "EJBCountryGroup.ejbgrpx": Entity Bean: "CountryBean" Invalid bean method return type: expected: entitybean.countrykey actual: void in method: public void entitybean.countrybean.ejbcreate(java.lang.string) throws java.rmi.remoteexception,javax.ejb.createexception Creating a resource reference Switch to the CMP 1.1 Node in the structure pane. The CMP 1.1 Node in the structure pane Here we will specify to which columns the attributes of our entity bean will map. Enter the table to which the entity bean maps (Country). Click the Button Get Meta Data, and JBuilder will provide a list box displaying all available columns in this table. 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 CountryBean.java public CountryKey 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 CountryKey(country); 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 Borland Enterprise Server as shown in the previous chapter. Mapping class attributes to table columns Now we have specified all the necessary parts of the deployment descriptor. Verify it to check for errors. 20

21 If you switch to the Borland Enterprise Server Console you will see the deployed entity bean next to the session bean we deployed in the previous chapter. Now you may start the test client application in JBuilder. You should see the following results: -- Initializing bean access. -- Succeeded initializing bean access. -- Execution time: 3365 ms. -- Calling findbyprimarykey(ejbtest.entity.ejbentityk Succeeded: findbyprimarykey(ejbtest.entity.ejbenti Execution time: 70 ms. -- Return value from findbyprimarykey(ejbtest.entity Calling getcurrency() -- Succeeded: getcurrency() -- Execution time: 40 ms. -- Return value from getcurrency(): Dollar. The Borland Enterprise Server console showing the two deployed EJB As before, we want to create a test application using the JBuilder test client tool. Accordingly, we have to repeat the steps for generating an EJB Test Client as discussed in the previous section. We don't want to create a GUI application this time, however. Instead, we generate a main method and enter the two 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." public static void main(string[] args) { The entity bean at work Conclusion We hope this paper is helpful to those evaluating JBuilder and VisualAge for Java and to those planning to migrate existing applications to the JBuilder environment. Whether you are building GUI applications, applets, database applications, or EJBs, JBuilder provides tools to simplify Java application development and deployment, including integration with leading application servers such as Borland Enterprise Server and IBM WebSphere. For more information on JBuilder, please visit our Web site at client.findbyprimarykey("usa"); client.getcurrency(); The entity bean at work 100 Enterprise Way Scotts Valley, CA Made in Borland Copyright 2002 Borland Software Corporation. All rights reserved. All Borland brand and product names are trademarks or registered trademarks of Borland Software Corporation in the United States and other countries. Java is a trademark or registered trademark of Sun Microsystems, Inc. in the U.S. and other countries. CORBA is a trademark or registered trademark of Object Management Group, Inc. in the U.S. and other countries