Borland Software Jbuilder 2005 Users Manual Developing Applications For J2EE™ Servers

2015-02-02

: Borland-Software Borland-Software-Jbuilder-2005-Users-Manual-484130 borland-software-jbuilder-2005-users-manual-484130 borland-software pdf

Open the PDF directly: View PDF .
Page Count: 132 [warning: Documents this large are best viewed by clicking the View PDF Link!]

Developing Applications for J2EE™ Servers

JBuilder® 2005

Developing Applications for

J2EE™ Servers

Borland Software Corporation

100 Enterprise Way

Scotts Valley, California 95066-3249

www.borland.com

Refer to the file deploy.html located in the redist directory of your JBuilder product for a complete list

of files that you can distribute in accordance with the JBuilder License Statement and Limited

Warranty.

Borland Software Corporation may have patents and/or pending patent applications covering subject

matter in this document. Please refer to the product CD or the About dialog box for the list of

applicable patents. The furnishing of this document does not give you any license to these patents.

product names are trademarks or registered trademarks of Borland Software Corporation in the

United States and other countries. Java and all Java-based marks are trademarks or registered

trademarks of Sun Microsystems, Inc. in the United States and other countries. All other marks are

the property of their respective owners.

For third-party conditions and disclaimers, see the Release Notes on your JBuilder product CD.

Printed in the U.S.A.

JB2005j2eeapps 3E4R0804

0405060708-987654321

PDF

Contents

Chapter 1

Introduction 1

Documentation conventions . . . . . . . . . . . . . 1

Developer support and resources. . . . . . . . . . . 2

Contacting Borland Developer Support . . . . . . 3

Online resources. . . . . . . . . . . . . . . . . . 3

World Wide Web . . . . . . . . . . . . . . . . . . 3

Borland newsgroups . . . . . . . . . . . . . . . . 3

Usenet newsgroups . . . . . . . . . . . . . . . . 4

Reporting bugs . . . . . . . . . . . . . . . . . . 4

Chapter 2

Programming for the Java 2 Platform,

Enterprise Edition 5

Why are J2EE applications desirable? . . . . . . . . 5

Benefits of the multi-tier model . . . . . . . . . . 8

How JBuilder can help . . . . . . . . . . . . . . . . 9

Client tier technologies . . . . . . . . . . . . . . 9

Middle-tier technologies . . . . . . . . . . . . . . 9

Other J2EE technologies . . . . . . . . . . . . . 10

Preparing to deploy J2EE applications . . . . . . 11

Learning about J2EE . . . . . . . . . . . . . . . . . 11

Chapter 3

Creating applications with J2EE

technologies 13

Client-server applications . . . . . . . . . . . . . . . 14

Multi-tier applications . . . . . . . . . . . . . . . . . 15

Stand-alone clients . . . . . . . . . . . . . . . . . . 15

Consumers of dynamic web content. . . . . . . . 16

Java client calling EJBs . . . . . . . . . . . . . . 16

Web-centric applications . . . . . . . . . . . . . . . 17

Business to business . . . . . . . . . . . . . . . . . 17

Chapter 4

Configuring the target server settings 19

Supported servers . . . . . . . . . . . . . . . . . . 19

Setting up servers within JBuilder . . . . . . . . . . 20

Creating a duplicate configuration to edit . . . . . 22

Adding a service pack . . . . . . . . . . . . . . . . 22

The created libraries . . . . . . . . . . . . . . . . . 23

Selecting a server. . . . . . . . . . . . . . . . . . . 24

Setting up JDBC drivers . . . . . . . . . . . . . . . 26

Creating the .library and .config files . . . . . . . 26

Adding the JDBC driver to projects . . . . . . . . 27

Updating projects with the latest server settings . . . 27

Updating from an earlier version of JBuilder . . . . . 28

Chapter 5

Using JBuilder with Borland servers 29

Configuring Borland servers in JBuilder . . . . . . . 29

Borland Enterprise Server AppServer

Edition 6.0. . . . . . . . . . . . . . . . . . . . 29

Borland Enterprise Server AppServer

Edition 5.2.1. . . . . . . . . . . . . . . . . . . 31

Making the ORB available to JBuilder . . . . . . . . 34

Configurations, partitions, partition services,

and J2EE APIs . . . . . . . . . . . . . . . . . . . 34

Changing the management port . . . . . . . . . 37

Starting the configuration or server . . . . . . . . . 38

Remote deploying . . . . . . . . . . . . . . . . . . 40

Remote debugging. . . . . . . . . . . . . . . . . . 41

Remote debugging for Borland Enterprise

Server 6.0. . . . . . . . . . . . . . . . . . . . 41

Preparing to remote debug partitions

that are not managed in JBuilder . . . . . . 41

Preparing to remote debug partitions

that are managed in JBuilder . . . . . . . . 41

Remote debugging for Borland Enterprise

Server 5.2.1. . . . . . . . . . . . . . . . . . . 42

Preparing to remote debug before the

Borland Enterprise Server AppServer

Edition 5.2.1 is running . . . . . . . . . . . 42

Preparing to remote debug when the

Borland Enterprise Server AppServer

Edition 5.2.1 is already running . . . . . . . 42

Remote debugging in JBuilder . . . . . . . . . . 43

Web module workarounds . . . . . . . . . . . . . . 43

Displaying the Borland Management Console

in JBuilder . . . . . . . . . . . . . . . . . . . . . 44

International issues . . . . . . . . . . . . . . . . . 44

Borland servers and JDataStore 7.0. . . . . . . . . 44

Chapter 6

Using JBuilder’s CORBA tools 45

How JBuilder and the VisiBroker ORB

work together. . . . . . . . . . . . . . . . . . . . 45

RMI . . . . . . . . . . . . . . . . . . . . . . . . 46

Setting up JBuilder for CORBA applications. . . . . 47

Configuring VisiBroker when the Borland

Enterprise Server is installed . . . . . . . . . . 47

Configuring VisiBroker stand-alone . . . . . . . 48

Configuring the OrbixWeb ORB . . . . . . . . . 50

Adding a new configuration. . . . . . . . . . . . 51

Setting and viewing ORB build properties . . . . . . 52

Setting VisiBroker ORB properties . . . . . . . . 52

Setting build properties for the OrbixWeb

or other third-party ORBs . . . . . . . . . . . . 54

Setting and viewing IDL build properties . . . . . . . 55

Using the CORBA wizards . . . . . . . . . . . . . . 57

Sample IDL wizard . . . . . . . . . . . . . . . . 57

CORBA Client Interface wizard . . . . . . . . . . 57

CORBA Server Interface wizard. . . . . . . . . . 58

HTML CORBA Client wizard . . . . . . . . . . . 58

CORBA Server Application wizard . . . . . . . . 59

Use CORBA Interface wizard . . . . . . . . . . . 59

Chapter 7

Using JBuilder with BEA WebLogic

servers 61

Service packs. . . . . . . . . . . . . . . . . . . . . 61

Configuring JBuilder for WebLogic servers. . . . . . 61

Creating a duplicate configuration to edit . . . . . 63

Created libraries. . . . . . . . . . . . . . . . . . 64

Adding a service pack . . . . . . . . . . . . . . . 64

Selecting a server . . . . . . . . . . . . . . . . . . 64

Working in JBuilder . . . . . . . . . . . . . . . . . . 66

Using existing code . . . . . . . . . . . . . . . . 66

Creating WebLogic entity beans in JBuilder. . . . 67

Using the DD Editor . . . . . . . . . . . . . . . . 67

Compiling . . . . . . . . . . . . . . . . . . . . . 67

Starting the server . . . . . . . . . . . . . . . . . . 67

Remote deploying . . . . . . . . . . . . . . . . . . 68

WebLogic Application Sever 7.x and

WebLogic Platform Server 8.1 . . . . . . . . . . 68

Deploying J2EE modules as an

exploded directory . . . . . . . . . . . . . . 69

Mapping EJB project modules at runtime . . . 69

Redeploying individual classes. . . . . . . . . 70

WebLogic 8.x Platform Server deployment

features . . . . . . . . . . . . . . . . . . . . . 70

Remote debugging . . . . . . . . . . . . . . . . . . 71

Remote debugging of JavaServer Pages . . . . . 71

Updating projects with the latest server settings . . . 72

Chapter 8

Using JBuilder with IBM WebSphere

servers 73

Configuring JBuilder for WebSphere servers. . . . . 73

Selecting a server . . . . . . . . . . . . . . . . . . 75

Generating WebSphere deployment

descriptors for WebSphere 4.0 . . . . . . . . . . . 75

Starting the server . . . . . . . . . . . . . . . . . . 76

Deploying . . . . . . . . . . . . . . . . . . . . . . . 77

Using the DD Editor . . . . . . . . . . . . . . . . 77

WebSphere Application Server 5.x . . . . . . . . 77

Remote deploying . . . . . . . . . . . . . . . 77

Deploying locally . . . . . . . . . . . . . . . . 78

WebSphere Server 4.0 . . . . . . . . . . . . . . 78

Remote deploying . . . . . . . . . . . . . . . 78

Deploying locally . . . . . . . . . . . . . . . . 79

Enabling remote debugging . . . . . . . . . . . . . 79

WebSphere Application Server 5.x . . . . . . . . 79

WebSphere Single Server 4.0. . . . . . . . . . . 80

WebSphere Server Advanced Edition 4.0. . . . . 80

Container-managed persistence (CMP) 1.1

and 2.0 in WebSphere 5.x . . . . . . . . . . . . . 81

Chapter 9

Using JBuilder with JBoss servers 83

Configuring JBuilder for the JBoss application

server . . . . . . . . . . . . . . . . . . . . . . . .83

Selecting a server . . . . . . . . . . . . . . . . . . .84

Creating a JBoss service module . . . . . . . . . . .84

Copying an existing JBoss service module . . . .85

Creating a JBoss service node for an

existing service module archive (SAR) in

a directory outside your project. . . . . . . . . .87

Editing the JBoss service module deployment

descriptor . . . . . . . . . . . . . . . . . . . . . .88

MBeans . . . . . . . . . . . . . . . . . . . . . .88

Starting the server. . . . . . . . . . . . . . . . . . .88

Deploying locally . . . . . . . . . . . . . . . . . . .89

Deploying exploded web modules. . . . . . . . . . .90

Remote debugging . . . . . . . . . . . . . . . . . .90

JSP debugging . . . . . . . . . . . . . . . . . . . .91

Chapter 10

Using JBuilder with Tomcat 93

Selecting Tomcat as your project’s web server . . . .95

Running your servlet or JSP with Tomcat . . . . . . .96

Starting Tomcat . . . . . . . . . . . . . . . . . .96

Stopping Tomcat . . . . . . . . . . . . . . . . . .96

Changing Tomcat’s port number . . . . . . . . . .97

Creating a custom server.xml file with Tomcat . . .97

Debugging JSPs with Tomcat 4.1 . . . . . . . . .98

Chapter 11

Editing J2EE deployment descriptors 99

Displaying the DD Editor . . . . . . . . . . . . . . 100

Standard and server-specific pages. . . . . . . . . 101

Adding to and deleting from a deployment

descriptor . . . . . . . . . . . . . . . . . . . . . 102

Validating a deployment descriptor entry . . . . . . 103

Chapter 12

Integrating with Enterprise

Information Systems 105

Creating a connector module node in the

project pane . . . . . . . . . . . . . . . . . . . . 105

Creating an empty connector module . . . . . . 106

Copying an existing connector module. . . . . . 107

Creating a module node for an existing

module in a directory outside your project . . . 108

Creating a connector module node for an

existing archive (RAR) outside your project . . 109

Viewing the connector module deployment

descriptors . . . . . . . . . . . . . . . . . . . . . 110

Editing the resource adapter descriptors . . . . . . 111

Authentication Mechanism page . . . . . . . . . 112

Configuration Property page . . . . . . . . . . . 113

Security Permission page . . . . . . . . . . . . 113

Server-specific pages . . . . . . . . . . . . . . . . 114

Compiling the connector module . . . . . . . . . . 114

iii

Chapter 13

Building J2EE modules 115

J2EE modules . . . . . . . . . . . . . . . . . . . 115

Setting module build properties . . . . . . . . . . . 116

File type filters . . . . . . . . . . . . . . . . . . 116

Class and resource filters . . . . . . . . . . . . 116

Clean filters . . . . . . . . . . . . . . . . . . . 117

Dependencies . . . . . . . . . . . . . . . . . . 117

Adding custom file types . . . . . . . . . . . . . . 117

Sample build scenarios . . . . . . . . . . . . . . . 118

EJB JAR without any bean classes . . . . . . . 118

EJB JAR with custom files . . . . . . . . . . . . 118

EJB JAR without EJB designer XML

descriptors . . . . . . . . . . . . . . . . . . . 119

WAR with custom descriptor(s) in the

WEB-INF directory . . . . . . . . . . . . . . . 119

WAR without any classes. . . . . . . . . . . . . 119

WAR with custom class filters . . . . . . . . . . 119

WAR with custom file types. . . . . . . . . . . .119

EAR with custom files . . . . . . . . . . . . . . 120

RAR with classes and dependencies. . . . . . .120

Application client module with classes and

dependencies . . . . . . . . . . . . . . . . . . 120

Improving module build performance . . . . . . . . 121

Web modules . . . . . . . . . . . . . . . . . . . 121

Index 123

Chapter 1: Introduction 1

Chapter

Chapter 1Introduction

Developing Applications for J2EE Servers introduces you to the various technologies

that make up the Java™ 2 Platform, Enterprise Edition (J2EE™), explains why they

are important, and describes how you can use JBuilder to create J2EE applications

that target your application server. You’ll learn how to configure JBuilder to work with

your server, and how to accomplish the essential programming tasks of running your

applications, debugging them remotely, and deploying them to your server.

Documentation conventions

The Borland documentation for JBuilder uses the typefaces and symbols described in

the following table to indicate special text.

Table 1.1 Typeface and symbol conventions

Typeface Meaning

Bold Bold is used for java tools, bmj (Borland Make for Java), bcj (Borland

Compiler for Java), and compiler options. For example: javac, bmj,

-classpath.

Italics Italicized words are used for new terms being defined, for book titles, and

occasionally for emphasis.

Keycaps This typeface indicates a key on your keyboard, such as “Press Esc to

exit a menu.”

Monospaced type Monospaced type represents the following:

■text as it appears onscreen

■anything you must type, such as “Type Hello World in the Title field

of the Application wizard.”

■file names

■path names

■directory and folder names

■commands, such as SET PATH

■Java code

■Java data types, such as boolean, int, and long.

■Java identifiers, such as names of variables, classes, package

names, interfaces, components, properties, methods, and events

■argument names

■field names

■Java keywords, such as void and static

2Developing Applications for J2EE Servers

Developer support and resources

JBuilder is available on multiple platforms. See the following table for a description of

platform conventions used in the documentation.

Developer support and resources

Borland provides a variety of support options and information resources to help

developers get the most out of their Borland products. These options include a range of

Borland Technical Support programs, as well as free services on the Internet, where

you can search our extensive information base and connect with other users of Borland

products.

[ ] Square brackets in text or syntax listings enclose optional items. Do not

type the brackets.

< > Angle brackets are used to indicate variables in directory paths,

command options, and code samples. JDK 5.0 uses angle brackets to

denote generics.

For example, <filename> may be used to indicate where you need to

supply a file name (including file extension), and <username> typically

indicates that you must provide your user name.

When replacing variables in directory paths, command options, and code

samples, replace the entire variable, including the angle brackets (< >).

For example, you would replace <filename> with the name of a file, such

as employee.jds, and omit the angle brackets.

See “Using command-line tools” in Building Applications with JBuilder for

more information.

Note: Angle brackets are used in HTML, XML, JSP, and other tag-based

files to demarcate document elements, such as <font color=red> and

<ejb-jar>. The following convention describes how variable strings are

specified within code samples that are already using angle brackets for

delimiters.

Italics, serif This formatting is used to indicate variable strings within code samples

that are already using angle brackets as delimiters. For example,

<url="jdbc:borland:jbuilder\\samples\\guestbook.jds">

... In code examples, an ellipsis (…) indicates code that has been omitted

from the example to save space and improve clarity. On a button, an

ellipsis indicates that the button links to a selection dialog box.

Table 1.2 Platform conventions

Item Meaning

Paths Directory paths in the documentation are indicated with a forward slash (/).

For Windows platforms, use a backslash (\).

Home directory The location of the standard home directory varies by platform and is

indicated with a variable, <home>.

■For UNIX, Linux, and OS X, the home directory can vary. For example,

it could be /user/<username> or /home/<username>

■For Windows NT, the home directory is C:\Winnt\Profiles\

■For Windows 2000 and XP, the home directory is C:\Documents and

Settings\<username>

Screen shots Screen shots reflect the Borland Look & Feel on various platforms.

Table 1.1 Typeface and symbol conventions (continued)

Typeface Meaning

Chapter 1: Introduction 3

Developer support and resources

Contacting Borland Developer Support

Borland offers several support programs for customers and prospective customers.

You can choose from several categories of support, ranging from free support upon

installation of the Borland product, to fee-based consultant-level support and extensive

assistance.

For more information about Borland’s developer support services, see our web site at

http://www.borland.com/devsupport/, call Borland Assist at (800) 523-7070, or contact

our Sales Department at (831) 431-1064.

When contacting support, be prepared to provide complete information about your

environment, the version of the product you are using, and a detailed description of the

problem.

For support on third-party tools or documentation, contact the vendor of the tool.

Online resources

You can get information from any of these online sources:

World Wide Web

Check the JBuilder page of the Borland website, www.borland.com/jbuilder, regularly.

This is where the Java Products Development Team posts white papers, competitive

analyses, answers to frequently asked questions, sample applications, updated

software, updated documentation, and information about new and existing products.

You may want to check these URLs in particular:

■http://www.borland.com/jbuilder/ (updated software and other files)

■http://info.borland.com/techpubs/jbuilder/ (updated documentation and other

files)

■http://bdn.borland.com/ (contains our web-based news magazine for developers)

Borland newsgroups

When you register JBuilder you can participate in many threaded discussion groups

devoted to JBuilder. The Borland newsgroups provide a means for the global

community of Borland customers to exchange tips and techniques about Borland

products and related tools and technologies.

You can find user-supported newsgroups for JBuilder and other Borland products at

http://www.borland.com/newsgroups/.

World Wide Web http://www.borland.com/

http://info.borland.com/techpubs/jbuilder/

Electronic newsletters To subscribe to electronic newsletters, use the online form at:

http://www.borland.com/products/newsletters/index.html

4Developing Applications for J2EE Servers

Developer support and resources

Usenet newsgroups

The following Usenet groups are devoted to Java and related programming issues:

■news:comp.lang.java.advocacy

■news:comp.lang.java.announce

■news:comp.lang.java.beans

■news:comp.lang.java.databases

■news:comp.lang.java.gui

■news:comp.lang.java.help

■news:comp.lang.java.machine

■news:comp.lang.java.programmer

■news:comp.lang.java.security

■news:comp.lang.java.softwaretools

Note These newsgroups are maintained by users and are not official Borland sites.

Reporting bugs

If you find what you think may be a bug in the software, please report it to Borland at

one of the following sites:

■Support Programs page at http://www.borland.com/devsupport/namerica/. Click the

Information link under “Reporting Defects” to open the Welcome page of Quality

Central, Borland’s bug-tracking tool.

■Quality Central at http://qc.borland.com. Follow the instructions on the Quality

Central page in the “Bugs Report” section.

■Quality Central menu command on the main Tools menu of JBuilder (Tools|Quality

Central). Follow the instructions to create your QC user account and report the bug.

See the Borland Quality Central documentation for more information.

When you report a bug, please include all the steps needed to reproduce the bug,

including any special environmental settings you used and other programs you were

using with JBuilder. Please be specific about the expected behavior versus what

actually happened.

If you have comments (compliments, suggestions, or issues) for the JBuilder

documentation team, you may email jpgpubs@borland.com. This is for documentation

issues only. Please note that you must address support issues to developer support.

JBuilder is made by developers for developers. We really value your input.

Chapter 2: Programming for the Java 2 Platform, Enterprise Edition 5

Chapter

Chapter 2Programming for the Java 2 Platform,

Enterprise Edition

The Java™ 2 Platform, Enterprise Edition (J2EE™) is an architecture for a Java

development platform for distributed enterprise applications. It was developed by Sun

Microsystems, with input from the development community, including Borland. J2EE

platform products, such as the Borland Enterprise Server, offer the developer the

capability of building applications with these benefits:

■Reliability and scalability, so business transactions are processed quickly and

accurately.

■Excellent security to protect users’ privacy and the integrity of the enterprise’s data.

■Ready availability, to meet the increasing demands of the global business

environment.

JBuilder is a Java integrated development environment that, when coupled with a

supported application server from companies such as Borland, BEA, and IBM greatly

simplifies and speeds the development of J2EE applications.

Why are J2EE applications desirable?

In the early 1990s, information systems frequently used a client-server architecture.

The user interface to the application usually ran on a desktop computer. This was the

client tier. The enterprise data being accessed by the client resided in a database and

6Developing Applications for J2EE Servers

Why are J2EE applications desirable?

was “served up” by a server. This approach initially promised improved scalability and

functionality.

Through hard experience, however, the development community learned that building

and maintaining a flexible distributed system is very difficult using the client-server

model. For example, the business logic of the application was in the client application.

Every time that logic needed modification, the revised application had to be installed on

every client machine in the enterprise. Maintenance became a nightmare. These

applications also had to manage transactions, be concerned with security, and process

the data efficiently, all the while presenting an attractive, easy-to-understand interface

to its users. Few developers have talents in all these areas. While a client-server

architecture might be adequate for some environments, most of today’s global

companies demand considerably more than the client-server model can deliver.

Once the limitations of the client-server approach became apparent, the development

community began seeking a better way. The result is the multi-tier model.

In the multi-tier model, the logic involved in presenting the user interface of the

application to the user lives on the middle tier. The business logic is now on the middle

tier also. When changes are needed, they can be updated in one place instead of on

each client machine.

Chapter 2: Programming for the Java 2 Platform, Enterprise Edition 7

Why are J2EE applications desirable?

This expanded diagram shows you the various components you might find running on

the various tiers:

The client in a J2EE application can be a JavaServer Page (JSP), HTML page, or

applet running in a browser; a Java application on a desktop machine; or even a Java

client on some portable device, such as a personal digital assistant (PDA) or cell

phone.

The middle-tier can have a servlet or a JSP-generated servlet running on a web server.

These elements usually make up the server-side presentation logic. An EJB container

provides a runtime environment for Enterprise JavaBeans™, which contain the

business logic of application. Both a web server and an Enterprise JavaBeans (EJB)

container provide services to the components that run on them. Because these

services are always available, programmers don’t have to include them in the

components they write.

The Enterprise Information System (EIS) tier is a repository for the enterprise’s data.

Usually it consists of the data in a relational database system.

Few J2EE applications have all of these components. They can be mixed and matched

in very flexible ways to meet the needs of the enterprise. See Chapter 3, “Creating

applications with J2EE technologies” for more on this topic.

8Developing Applications for J2EE Servers

Why are J2EE applications desirable?

Benefits of the multi-tier model

The multi-tier approach adopted by the J2EE platform has several benefits:

■It reduces the complexity of distributed development with a simplified architecture

and the sharing of the work load among roles.

The business logic of the application runs in the middle tier inside an Enterprise

JavaBean (EJB) container and/or on a web server. These containers and servers

can handle many of the difficult tasks for developers. For example, an EJB container

can handle transactions, instance pooling, and data persistence without requiring

the EJB programmer to write the logic to perform these tasks. A web server can

create and pool instances of servlet classes and handle multiple threads and socket

connections. Instead of writing the code to do these things, a member of the

development team specifies the desired behavior at deployment time.

Members of the development team play different roles. Each is a specialist in one or

more areas. For example, the content of an HTML page or stylesheet would likely

be created by a graphic designer or webmaster. A senior developer might be

responsible for the business logic of the application encapsulated within Enterprise

JavaBean components. A web developer might develop the user interface and

presentation logic using JavaServer Pages (JSPs) and servlets. An application

assembler takes the various components of the application and puts it all together,

often creating an Enterprise Archive (EAR) file and creating the deployment

descriptor that explains how the application is to be deployed. The application

deployer and administrator deploy the application. By partitioning the work this way,

each step of the development/deployment process is handled by someone skilled in

their area while no one has to be an expert in every area.

■It is highly scalable, allowing the development of systems to meet many different

needs that can change quickly.

When demands on the system increase, the logic can be updated easily in one

place on the middle tier without having to load new logic on every client machine.

■New applications can integrate well with existing information systems.

JDBC, a J2EE technology, is a Java API to SQL databases, permitting the access to

any type of tabular data that might exist in the enterprise. The Java Naming and

Directory Interface (JNDI) allows applications that use Java technology to access

enterprise naming and directory services. The J2EE Connector architecture gives

Java applications connections to heterogeneous legacy systems. The Java

Message Service (JMS) is the Java API for sending and receiving messages though

enterprise messaging systems. CORBA services are called using JavaIDL.

■Security is enhanced.

J2EE technologies are designed with security in mind. For example, only users in

assigned roles can access certain methods in enterprise beans. Who can access

these methods isn’t coded in the enterprise beans themselves. Instead this

information is set in the enterprise beans’ deployment descriptors, which are used

by the deployer to establish their behavior after they are deployed. This type of

security is called declarative security.

For complex security requirements, however, J2EE also allows programmable

security. In these cases, the security logic is placed within the code itself.

■Developers can choose from a variety of development tools, servers, and

components to develop the applications they need.

The development team can select the solutions that are best for their needs, without

becoming locked into the offerings of a single vendor.

Chapter 2: Programming for the Java 2 Platform, Enterprise Edition 9

How JBuilder can help

JBuilder Enterprise Edition has many features to help your team develop J2EE

applications. These are the technologies JBuilder has to help you develop the client

tier:

Client tier technologies

■Applets

Applets are a special kind of Java application that are downloaded and run by a web

browser on a client machine. To begin developing an applet in JBuilder, start with

the Applet wizard. For information about working with applets, see “Working with

applets” in Developing Web Applications.

■Java user interface applications

JBuilder has several features that can help you develop an application that runs on

a client machine. Begin a Java application using the Application wizard. Continue

designing your user interface by using JBuilder’s UI designer. You create your UI by

adding UI components from JBuilder’s component palette. For information on

working with JBuilder’s UI designer, see “Visual design in JBuilder” in Designing

Applications with JBuilder.

If you want to create your own JavaBean components to use in your user interface,

BeansExpress can simplify the task for you. For information about using

BeansExpress, see “Creating JavaBeans with BeansExpress” in Designing

Applications with JBuilder. JBuilder’s DataExpress components for enterprise beans

make it easier for you to build client applications using database-aware visual

components such as dbSwing or InternetBeans Express. For more information

about DataExpress for EJB, see “Using the DataExpress for Enterprise JavaBeans

components” in Developing Applications with Enterprise JavaBeans.

Both a web server and/or an EJB container can run on the middle tier. JBuilder

ships with Tomcat, a servlet container that can be used as a web server, and with

the Borland Enterprise Server 5.2.1, which contains the EJB container. You can

build applications for these servers or you can set up JBuilder to enable you to

develop applications for BEA WebLogic 7.x, and 8.1, IBM WebSphere 4.0 and 5.0,

Sun-Netscape iPlanet 6.0 and 6.5, and Sybase 4.1 and 4.2.

Middle-tier technologies

These are the middle-tier J2EE technologies that use a web server:

■Servlets

A servlet is a server-side Java application that can process requests from clients.

The servlet responds to the request by generating dynamic output that is sent back

to the client. You can begin developing servlets with JBuilder’s Standard Servlet

wizard. To find out more about servlets and developing them, see “Developing

servlets” in Developing Web Applications.

■JavaServer Pages (JSPs)

An extension of servlet technology, JSPs offer a simplified way to develop servlets.

Like servlets, they generate dynamic output that is sent back to the client’s web

browser, thus bridging the client and middle tier. Begin developing JSPs with

JBuilder’s JavaServer Page wizard. To find out more about JSPs and developing

them, see “JavaServer Pages (JSP)” in Developing Web Applications.

InternetBeans Express is a component library that supplements the servlet and JSP

technology available in JBuilder. This library makes it easy to present and

10 Developing Applications for J2EE Servers

How JBuilder can help

manipulate data from a database so you can build data-aware servlets and JSPs.

For information about InternetBeans Express, see “Using InternetBeans Express” in

the Developing Web Applications.

This is the middle-tier J2EE technology that uses an EJB container:

■Enterprise JavaBeans (EJBs)

Enterprise JavaBeans are server-side components that contain the business logic of

the application. JBuilder assists you in building EJB 1.x and EJB 2.0 components.

Start building enterprise beans by using the EJB wizards on the Enterprise page of

the object gallery (File|New|Enterprise). For building EJB 2.0 components, JBuilder

offers the EJB designer, a Two-Way Tool™ that allows you to design your beans

visually all the while keeping your code, deployment descriptors, and design

synchronized. For more information about building, testing, and deploying

enterprise beans, see “An introduction to EJB development” in Developing

Applications with Enterprise JavaBeans.

As you create your enterprise beans, JBuilder is building your EJB deployment

descriptors. You can use JBuilder’s EJB DD Editor to modify them as you wish. For

more information about the EJB DD Editor see Chapter 11, “Editing J2EE

deployment descriptors” and “Editing EJB deployment descriptors” in Developing

Applications with Enterprise JavaBeans.

All the web application components and enterprise bean components can be combined

and delivered in an application module. JBuilder has an Application Module wizard. For

more information, see “Creating an application module” in the “Deploying enterprise

beans” chapter of the Developing Applications with Enterprise JavaBeans book.

Other J2EE technologies

While not confined to a particular architectural tier, these technologies are enablers

that make things work:

■Java Database Connectivity (JDBC)

JDBC is the standard used to access your database on the Enterprise Information

Systems (EIS) tier. It defines a Java API you use to write SQL statements that are

sent to your database.

JBuilder includes DataExpress, a component library for accessing data in your

database. It connects your application to your database using JDBC drivers.

JBuilder also includes JDataStore, an all-Java embedded database and component

library. You access JDataStore using JDBC.

Entity beans that access rows in your database, also connect to your data using

JDBC.

■Java Message Service (JMS)

JMS is an enterprise messaging service that routes messages between

components and processes in a distributed application.

The Borland Enterprise Server includes SonicMQ, a JMS implementation. Also

JBuilder supports EJB 2.0 components, which include message-driven beans.

Message-driven beans integrate JMS into enterprise beans. JBuilder also includes a

JMS wizard. See “Creating JMS producers and consumers” in Developing

Applications with Enterprise JavaBeans for information on creating classes and

applications that can create and consume JMS messages.

■Java Naming and Directory Interface (JNDI)

All J2EE servers use JNDI, a Java naming service used to locate distributed

objects.

Chapter 2: Programming for the Java 2 Platform, Enterprise Edition 11

Learning about J2EE

■Extensible Markup Language (XML)

Although not really a J2EE technology, XML is widely used by J2EE technologies.

For example, web components and enterprise beans have their deployment

descriptors written in XML. These deployment descriptors describe how the

components behave once they are deployed.

JBuilder has several XML features that help you accomplish common programming

tasks you might encounter in your J2EE projects. For information about JBuilder’s

XML features, see “Introduction” in Working with XML.

Preparing to deploy J2EE applications

As you create and compile your web applications and enterprise beans, JBuilder can

create the WAR (Web Archive) and EJB-JAR (EJB Archive) files for you automatically.

You can choose to bundle the components of a J2EE application together into an EAR

file. JBuilder provides an Application Module wizard to help you do this. For more

information, see “Creating an application module” in Developing Applications with

Enterprise JavaBeans.

Learning about J2EE

If you’ve read this far, you’ve been exposed very briefly to many concepts and, with all

the acronyms to identify J2EE technologies, an alphabet soup. To develop a deeper

understanding of J2EE benefits and concepts, begin your explorations on Sun’s

www.java.sun.com web site. This http://java.sun.com/j2ee/docs.html link takes you to

Sun’s J2EE documentation home page where you can find an abundance of useful

information.

If you’re new to J2EE programming, look at the J2EE tutorial at http://java.sun.com/

j2ee/tutorial/index.html. For an in-depth discussion of J2EE programming and the

recommended programming practices to use in your J2EE applications, don’t miss the

very detailed J2EE Blueprints, found at http://java.sun.com/j2ee/blueprints/

index.html. J2EE Blueprints is an integral part of J2EE itself. You’ll find it useful when

you need to understand deeper concepts and are looking for the best ways to

approach J2EE development. This material is also available in book form as Designing

Enterprise Applications with the Java 2 Platform, Enterprise Edition written by Nicholas

Kassem and the Enterprise Team of Sun. http://java.sun.com/j2ee/blueprints/

aboutthebook.html links you to information about the book.

You’ll find additional documentation and specifications for the various J2EE

technologies on the Sun site. There are also excellent third-party books, but because

J2EE is a developing product, be aware which versions of the various technologies

they address.

12 Developing Applications for J2EE Servers

Chapter 3: Creating applications with J2EE technologies 13

Chapter

Chapter 3Creating applications with J2EE

technologies

The Developing Web Applications, Developing Applications with Enterprise

JavaBeans, and other parts of JBuilder’s documentation explain how to use J2EE

technologies. They describe in depth how to use JBuilder features to develop web

applications, work with XML, develop Enterprise JavaBeans, access and work with

your data using DataExpress, and create web services. Within each of these areas of

the documentation, you should find the information to understand these technologies

and work productively with them.

But today’s web-based enterprise applications usually use several J2EE technologies.

How do these disparate technologies fit together in applications you and your team

might develop? Which technologies are right for which kind of applications? This

chapter intends to help you see how the pieces fit together, while highlighting the

flexibility of J2EE applications. It borrows heavily from the Introduction chapter of

Designing Enterprise Applications with the J2EE Platform by Inderjeet Singh, Beth

Stearns, Mike Johnson, and the Sun Enterprise Team. You can find the book online on

the Sun web site at http://java.sun.com/blueprints/guidelines/

designing_enterprise_applications_2e/#chapters, and it is also available for purchase.

14 Developing Applications for J2EE Servers

Client-server applications

Here’s the diagram from the previous chapter showing the multiple tiers used in most

J2EE applications:

The diagram shows you all the different types of entities found on each tier, but it

doesn’t show you the common ways J2EE applications combine these technologies to

create reliable, scalable, and easily distributed applications.

Client-server applications

Before looking at multi-tier J2EE models, consider the old standard, the two-tier client-

server model. Using J2EE technologies does not preclude you from creating client-

server applications. Client-server applications omit the middle tier shown in the multi-

tier application diagram. While the client-server model scales poorly and maintaining

and distributing such applications is more difficult, sometimes a Java client on a

desktop that accesses the data of the company directly is all you really need.

The Java client can contain both the presentation and business logic, although it’s

possible one application could handle the presentation tasks while another could

Chapter 3: Creating applications with J2EE technologies 15

Multi-tier applications

handle business logic, all on the client tier. You would use JDBC or Connectors to

access the data on the Enterprise Information System (EIS) tier.

Consider using the client-server model only when the number of desktops running

clients is quite small and will remain so. Once the demand for more than a few client

instances increases, you should probably consider another type of application

architecture.

Multi-tier applications

Here you see the classic multi-tier, distributed architecture that uses three tiers: the

browser on the client tier, the web container and EJB container on the middle tier that

runs on a J2EE server, and the Enterprise Information Systems (EIS) tier that is

managed by a database system. Such an application uses web components such as

JavaServer Pages (JSPs), servlets, and XML to manage the application’s presentation

logic. The EJB container contains enterprise beans that respond to requests from the

web tier components and access the data in the EIS tier.

When should you use JavaServer Pages and when should you use servlets?

JavaServer Pages are intended as user interface components. Servlets are usually

used for processing requests and controlling application logic.

XML can be very important in multi-tier applications. XML data messages use HTTP as

their transport protocol. Such data messages can encapsulate all types of data and

respond to a variety of client types, including XML-enabled browsers.

Stand-alone clients

Not all multi-tier applications use a browser on the client tier. Often the client is a Java

client or a client written in another language that consumes dynamic web content or an

application that interacts directly with enterprise beans running in an EJB container.

This diagram shows you the possibilities of this type of application:

Note that this diagram includes the client-server application also as such an application

includes a stand-alone client, too.

16 Developing Applications for J2EE Servers

Stand-alone clients

Consumers of dynamic web content

One type of stand-alone client is a Java application or another programming language

that consumes dynamic web content. This web content is usually XML data messages:

The web container performs the XML transformations and provides web connectivity to

clients. The client handles the presentation logic while the web tier manages the

business logic and accesses the data on the EIS tier if necessary. Business logic might

be implemented as enterprise beans. The J2EE technologies likely to be used are

XML, servlets, web services, and possibly enterprise beans and JDBC to access

enterprise data.

Java client calling EJBs

Enterprise JavaBeans (EJBs) are server-side components that run in a middle-tier EJB

container. The container provides services to the beans, such as transaction

management and security. You, as the developer, don’t have to implement such low-

level and complex services, but instead can concentrate on developing the business

logic for the beans, knowing that the services are there when they are needed.

Developers often choose EJBs when building applications that will be distributed over

several servers. They also like to use EJBs because of the transparent way they

handle transactions.

The following diagram depicts a Java client that calls upon the business methods

encapsulated with the enterprise beans that are running in an EJB container. If the

beans are entity beans, they access company data on the EIS tier through JDBC and

J2EE connectors. Ideally, the client should access company data through a session

bean which interacts with the entity beans that model company data. A session bean

that interacts with an entity bean in this way is usually using the Session Facade

design pattern; see “Creating session facades for entity beans” in Developing

Applications with Enterprise JavaBeans for more information. XML is used in the

deployment descriptors for enterprise beans.

If the application you need requires secure transactions over a distributed system,

consider using enterprise beans.

Chapter 3: Creating applications with J2EE technologies 17

Web-centric applications

There are times when your application just doesn’t need to use enterprise beans and if

you do so, you add a layer of complexity. If your application doesn’t require

transactions on a distributed system, consider a web-centric application model:

This scenario puts both the presentation and business logic on the web tier. The web

container can host JavaServer Pages and servlets. The client is simply a browser and

data is transferred using XML, HTTP protocol, and/or HTML pages. Servlets can

access the EIS tier, when necessary, using JDBC or connectors. Applications using

this type of architecture are quite common.

Business to business

When you need a web-based commerce solution, consider the business-to-business

model. This might include multiple web containers and multiple EJB containers.

Web container to web container architecture is suitable for ecommerce solutions.

Communication takes place through XML data message over HTTP. Such applications

are very loosely coupled.

Peer-to-peer communication between EJB containers offers a more tightly coupled

model that works well for intranet solutions. In these types of applications, seriously

consider using message-driven enterprise beans and Java Message Service (JMS),

which enable you to develop loosely coupled applications.

18 Developing Applications for J2EE Servers

Chapter 4: Configuring the target server settings 19

Chapter

Chapter 4Configuring the target server

settings

Before you begin creating enterprise applications, you must configure the settings for

the application server and/or web server to which you are going to deploy.

Tip Be sure to see the server-specific chapters for the various servers to find additional

configuration information for each server. These are the chapters:

■Chapter 5, “Using JBuilder with Borland servers”

■Chapter 7, “Using JBuilder with BEA WebLogic servers”

■Chapter 8, “Using JBuilder with IBM WebSphere servers”

■Chapter 9, “Using JBuilder with JBoss servers”

■Chapter 10, “Using JBuilder with Tomcat”

Supported servers

JBuilder supports the following servers:

■Borland Enterprise Server 5.2.1

■Borland Enterprise Server 6.0.1

■BEA WebLogic Server 7.0 SP 5

■BEA WebLogic Platform 8.1 SP 3

■IBM WebSphere Application Server 4.0.7 Single Server

■IBM WebSphere Application Server 4.0.7 Advanced Edition

■IBM WebSphere Application Server 5.0.2.4, 5.1.0.4

■JBoss Application Server 3.0.8

■JBoss Application Server 3.2.5

■Tomcat 4.1.30

■Tomcat 5.0.27

20 Developing Applications for J2EE Servers

Setting up servers within JBuilder

This is a feature of

JBuilder Developer

and Enterprise

To configure the settings to target one or more application servers,

1Choose Enterprise|Configure Servers. The Configure Servers dialog box is

displayed:

The left side of the dialog box lists the servers that can be configured in JBuilder and

for which JBuilder finds a registered OpenTool.

2Select the server you want to configure by clicking it in the pane on the left.

The right side of the dialog box lists the default settings for the selected server. Each

application server except Generic App Server 1.0 and all versions of Tomcat has

both a General and a Custom page for editing settings. The General page has fields

that all the application servers have in common, while the Custom page has fields

that are specific to the selected application server. In some cases, modifying a

Custom setting will update a setting on the General page and vice versa.

The Generic AppServer 1.0 server option is a generic option. It represents a basic

application server that supports EJB 1.1 and/or EJB 2.0 development. Select it if the

application server you use is not currently supported by JBuilder. You will probably

want to edit the resulting deployment descriptor with tools supplied with that

application server to get the exact settings you want. You could also choose this

option if the you aren’t targeting a specific application server.

3Check the Enable Server check box at the top of the dialog box.

Checking this option enables the fields for the selected application server. You won’t

be able to edit any fields until it is checked. The Enable Server check box also

determines whether this server will appear in the list of servers when you select a

server for your project using the Server page of the Project|Project Properties dialog

box.

JBuilder provides default settings for the selected server. If JBuilder’s default

settings are not appropriate, edit any of the settings as needed. Some servers

require you to enter settings in addition to the defaults. Clicking the OK button in this

Chapter 4: Configuring the target server settings 21

Setting up servers within JBuilder

dialog box when not all required values are set or selecting another server while the

current one is enabled displays a message dialog box that informs you about the

missing settings and usually selects the control representing the missing setting.

4If you want to change any of the settings, click the ellipsis (…) button next to the field

and make your changes.

You can add any necessary application dependencies to the server’s classpath by

clicking the Required Libraries tab and using the Add button to add the libraries the

server needs.

5Click the Custom tab to view settings unique to the server. Most application servers

allow you to specify the location of the JDK the server uses; some require you to

specify the JDK location for successful configuration completion. Updates you make

on the Custom page can update settings on the General page. (Note that Tomcat

configurations do not have a Custom tab.)

Following are the JDKs and their installed locations for the application servers

supported by JBuilder:

■Borland Enterprise Server AppServer Edition 5.2.1: <bes home>/jdk/jdk1.3.1 or

<bes home>/jdk/jdk1.4.1 (the default value)

■Borland Enterprise Server AppServer Edition 6.0: <bes home>/jdk/jdk1.4.2

■WebLogic Server 7.x: <bea home>/jdk131_10

■WebLogic Platform Server 8.1: <bea home>/jdk141_04. WebLogic 8.1 also

supports JRockit (a JDK optimized for server applications), so the JDK directory

could be <bea home>/jrockit81sp3_142_04

■WebSphere 4.x (either Advanced Edition or Single Server): <websphere home>/

java

■WebSphere 5.x: <websphere home>/java

As you make your edits, JBuilder attempts to validate your settings. Once you’ve

made your edits, click the OK button to accept your changes and close the dialog

box. If you prefer that JBuilder not try to validate your changes, uncheck the Enable

Server dialog box. Selecting OK saves changes for all servers you’ve enabled,

disabled, or modified.

6Click OK when you are through configuring the application server.

When you click OK and the Enable Server check box is checked, JBuilder attempts

to verify your settings. If errors are detected, a message box containing information

about the errors appears and focus is given to the control appropriate for fixing the

error. If the Enable Server option is unchecked, the dialog box simply closes and no

setting validation is performed.

Once a server is properly configured and validated, the server you configured is listed

in black type in the pane on the left. Gray type indicates the server hasn’t been

configured yet. Red type indicates an error condition; specifically it means the server’s

library containing its settings has been read, but the OpenTool representing the server

can’t be found. You can delete a server shown in red by selecting it and clicking the

Delete button.

The Reset To Defaults button sets the settings back to the values they originally had

when JBuilder was first installed and the server is disabled.

If a dialog box appears with a message that you must restart JBuilder, you must close

and then restart JBuilder for changes to become effective; otherwise, restarting

JBuilder is not necessary.

22 Developing Applications for J2EE Servers

Adding a service pack

Creating a duplicate configuration to edit

Once you’ve created a server configuration, you might find you’d like to have a similar

one, but with some slight differences. Follow these steps to create a duplicate

configuration you can then edit:

1Choose Enterprise|Configure Servers to display the Configure Servers dialog box.

2Select the server configuration you would like to duplicate from the left pane.

3Click the Copy button at the bottom of the left pane to display the Copy Server

wizard:

4Specify the name you want to use to identify this server configuration in the Name

For This Server field.

5Specify the server version in the Version For This Server field.

6Click OK.

7Select your new configuration in the left pane of the Configure Servers dialog box

and make the changes to the settings you need using the General and Custom

pages.

Copying a server configuration also creates copies of that server’s tools. You could,

therefore, create a duplicate server configuration and modify just the server’s tools as

the only difference between the two configurations. As another example, you could

have the copied configuration refer to a different home directory if you have slightly

different versions of that server installed. You can also delete a server configuration in

the Configure Servers dialog box.

Adding a service pack

If you want to add a service pack to your application server configuration, follow these

steps:

1Choose Enterprise|Configure Servers.

2Select your server from the list of servers in the pane on the left side of the dialog

box.

3Click the General tab, then the Class tab, if it isn’t already selected.

4Click Add.

5Navigate to the location of the service pack JAR file.

6Click OK twice to close all dialog boxes.

Chapter 4: Configuring the target server settings 23

The created libraries

When you configure the server settings, one or more libraries are created for you

automatically in your JBuilder home directory that contain all the application server files

you will need for enterprise bean development with the application server of your

choice. These are the libraries created for you, listed by application server:

Borland Enterprise Server 6.0.1

■Borland Enterprise Server 6.0 Client: All JARs needed to run a client.

■Borland Enterprise Server 6.0 Servlet: Used for web applications.

Borland Enterprise Server 5.2.1

■Borland Enterprise Server 5.2.1 Client: All JARs needed to run a client.

■Borland Enterprise Server 5.2.1 Servlet: Used for web applications.

WebLogic 8.1

■WebLogic 8.1 Client: All JARs needed to run a client.

■WebLogic 8.1 Deploy: JARs needed to run the WebLogic 8.1 deploy tool.

■WebLogic 8.1 Servlet: Used for web applications.

WebLogic 7.x

■WebLogic 7.x Client: All JARs needed to run a client.

■WebLogic 7.x Deploy: JARs needed to run the WebLogic 7.x deploy tool.

■WebLogic 7.x Servlet: Used for web applications.

WebSphere 5.x

■WebSphere 5.x Client: JARs needed to run a client.

■WebSphere Application Server 5.x Ext Dirs: JARs used during server startup.

■WebSphere Application Server 5.x EJB Deploy: JARs used to compile enterprise

beans and create stubs.

■WebSphere Application Server 5.x Servlet: Used for web applications.

WebSphere 4.0 Single Server

■WebSphere AES 4.0 Client: JARs needed to run a client.

■WebSphere AES 4.0 Ext Dirs: JARs used during server startup.

■WebSphere AES 4.0 EjbDeploy: JARs used to compile enterprise beans and

create stubs.

■WebSphere AES 4.0 SeAppInstaller: JARs used to run the WebSphere 4.0

deploy tool (SeAppInstaller).

■WebSphere AES 4.0 Servlet: Used for web applications.

WebSphere 4.0 Advanced Edition

■WebSphere AE 4.0 Client: JARs needed to run a client.

■WebSphere AE 4.0 Ext Dirs: JARs used during server startup.

■WebSphere AE 4.0 XmlConfig: JARs used to run the WebSphere 4.0 AE deploy

tool.

■WebSphere AE 4.0 EjbDeploy: JARs used to compile enterprise beans can

create stubs.

■WebSphere AE 4.0 Servlet: Used for web applications.

24 Developing Applications for J2EE Servers

Selecting a server

JBoss 3.x+

■JBoss 3.x+ Client: JARs needed to run a client.

■JBoss 3.x+ Servlet: Used for web applications.

Tomcat

■Tomcat 4.1 Servlet: Used for web applications.

■Tomcat 5.0 Servlet: Used for web applications.

Selecting a server

JBuilder can target multiple servers. You can choose a single application server for all

stages of EJB and web application development, or you can choose different servers

for different aspects of development. For example, you can select one server to use to

develop enterprise beans and another to develop web applications.

To select one or more servers to use for your project,

1Choose Project|Project Properties.

2Select Server in the dialog box tree. The Server page is displayed:

3Decide whether you want to use a single server for all aspects of development or

different servers to handle different areas of development.

■To use a single server,

1Select the Single Server For All Services In Project option and select the

server from the drop-down list.

2If you want to make changes to the configuration settings for the server, click

the ellipsis (…) button and edit the settings you want on the General and

Custom pages. Click OK.

You can also use this dialog box to select a different server.

3If you don’t want a particular service started when the server starts up,

uncheck the check box next to the service in the Services list. This feature

currently applies only to the Borland Enterprise Server as it is the only one

which allows you to start and stop selected services.

If you uncheck the Deployment or Client JAR Creation services, the

corresponding menu items will be disabled on the JBuilder Enterprise menu. If

you uncheck the JSP/Servlet service, web server support is disabled. If you

uncheck the Naming/Directory service for Tomcat, naming service support is

disabled. If you uncheck the Deployment service, vendor-specific descriptors

won’t be generated and all deploy options will be disabled.

Chapter 4: Configuring the target server settings 25

Selecting a server

■To use different servers for different services,

1Select the Modular Services Provided By Different Servers option.

2Check the check boxes next to all the services for which you want to specify

an application server in the Services list.

3Click one of the checked services to select it in the Services list.

4In the Service Properties For Project group box, use the Server drop-down list

to select the server you want to use for this service.

If server-specific properties are available for the server you selected for the

particular service you are working with, they will appear below the Server

drop-down list. If the Deployment service is selected, a Build Target For

Deploying To Server drop-down list appears on the Service Properties For

Project panel. Select the type of build you want to occur. If the EJB service is

selected, you’ll see read-only information appear that is intended to help you

decide which server is appropriate for your needs.

If you select the JSP/Servlet service, the Default Runtime Host Name and

Default Runtime Port Number fields are available to you. The default values

refer to the global server configuration. If you change these values, they are

used for all server run configurations created after you made the change.

If you expand the Deployment service node, you can select from several

subnodes that have accompanying properties. The properties vary depending

on which is your selected server. All servers have a Build Target For

Deploying To Server field, however. Select your desired build option from the

drop-down list.

For Borland Enterprise Server only

The Deployment jndi-definitions.xml option determines whether the jndi-

definitions.xml file is included in any of the deployment actions you select.

Uncheck it if you don’t want it included. jndi-definitions.xml is an XML

deployment descriptor for EJB 2.0 resources.

For WebLogic 7.x – 8.1

If you expand the WebLogic Deployment service node and select the WARs

node, the service properties include a Map Project Webapps At Runtime

option. When this option is selected (the default value) all web applications in

the project deploy from the web application directory and not as a WAR when

the server starts up.

If you expand the WebLogic Deployment service node and select the EARs

node, the service properties include a Map Project EJB Modules At Runtime

option. When this option is selected (the default value) all EJBs in the project

deploy from the EJB directory and not as a EAR when the server starts up.

All the WebLogic Deployment service nodes have Deploy As Archive and

Deploy As Exploded Directory options. Checking the Deploy As Archive option

enables the archive to be deployed. Checking the Deploy As Exploded

Directory option means the archive is exploded into a directory as its contents

are deployed instead.

If you select the EJB service, the service properties include a combo box with

options to deploy data sources for all EJB modules in the project. These are

the options:

■Map Project Data Sources: Maps data sources for all EJB modules in

config.xml for the domain specified in the server configuration. DataSource

entries are removed when the server shuts down.

■Map And Persist Project Data Sources: Maps data sources for all EJB

modules in config.xml for the domain specified in the server configuration.

26 Developing Applications for J2EE Servers

Setting up JDBC drivers

Data Source information is persisted in config.xml. DataSource entries are

removed when the server shuts down.

■Do Not Map Project Data Sources: Does not map any data sources.

Note that JBuilder also adds the JDBC driver (if it can be located in the

project’s required libraries) to the server’s classpath at start up time. All data

sources created by JBuilder are transactional data sources.

5If you want to make changes to the configuration settings for the server

selected for the service, click the ellipsis (…) button and edit the settings you

want on the General and Custom pages. Click OK.

6Repeat these steps for each service you want access to.

4Click OK.

If you neglect to select one ore more servers for a project, the Server page of the

Project Properties dialog box appears when you start an EJB wizard from the object

gallery. All EJB projects must have one or more selected servers.

Setting up JDBC drivers

To enable JBuilder’s EJB wizards and EJB designer to access a database, you must

install the JDBC driver supplied by the database vendor and set up the driver in

JBuilder. Install a JDBC driver following the vendor’s instructions.

To begin setting up the driver in JBuilder, select Enterprise|Enterprise Setup to display

the Enterprise Setup dialog box. Select Database Drivers in the tree to display the

Database Drivers page. Use this page to add a new database driver to JBuilder. See

the following section for step-by-step instructions.

Creating the .library and .config files

There are three steps to adding a database driver to JBuilder:

1Creating a library file which contains the driver’s classes, typically a JAR file, and

any other auxiliary files such as documentation and source.

2Deriving a .config file from the library file which JBuilder adds to its classpath at

start-up.

3Adding the new library to your project, or to the Default project if you want it

available for all new projects.

The first two steps can be accomplished from the Database Drivers page:

1Open JBuilder and choose Enterprise|Enterprise Setup. Click the Database Drivers

tab which displays .config files for all the currently known database drivers.

2Click Add to add a new driver, then New to create a new library file for the driver.

The library file is used to add the driver to the required libraries list for projects.

Note You can also create a new library under Tools|Configure|Libraries, but since you

would then have to use Enterprise Setup to derive the .config file, it is simpler to do

it all here.

3Type a name and select a location for the new file in the Create New Library dialog

box.

4Click Add, and browse to the location of the driver. You can select the directory

containing the driver and all it’s support files, or you can select just the archive file

for the driver. Either will work. JBuilder will extract the information it needs.

Chapter 4: Configuring the target server settings 27

Updating projects with the latest server settings

5Click OK to close the file browser. This displays the new library at the bottom of the

library list and selects it.

6Click OK. JBuilder creates a new .library file in the JBuilder /lib directory with the

name you specified (for example, InterClient.library). It also returns you to the

Database Drivers page which displays the name of the corresponding .config file in

the list which will be derived from the library file (for example, InterClient.config).

7Select the new .config file in the database driver list and click OK. This places the

.config file in the JBuilder /lib/ext directory.

8Close and restart JBuilder so the changes to the database drivers will take effect,

and the new driver will be put on the JBuilder classpath.

Important If you make changes to the .library file after the .config file has been derived, you must

re-generate the .config file using Enterprise Setup, then restart JBuilder.

Now that JBuilder can see the database driver, you must add the database driver

library to the Required Libraries list in Project|Properties, or Project|Default Properties.

Adding the JDBC driver to projects

Projects run from within JBuilder use only the classpath defined for that project.

Therefore, to make sure the JDBC driver is available for all new projects that will need

it, define the library and add it to your default list of required libraries. This is done from

within JBuilder using the following steps:

1Start JBuilder and close any open projects.

2Choose Project|Default Project Properties.

3Select the Required Libraries tab on the Paths page, then click the Add button.

4Select the new JDBC driver from the library list and click OK.

5Click OK to close the Default Project Properties dialog box.

Note You can also add the JDBC driver to an existing project. Just open the project, then

choose Project|Properties and use the same process as above.

Updating projects with the latest server settings

If a server configuration has been modified since a project was last opened, JBuilder

updates it with the latest server settings for the project’s selected server(s). So, for

example, if you have modified server settings for one project and you have others that

aren’t open that use the same server configuration, the next time you open those other

projects, your modified server settings will be in force automatically. If you want to use

a similar but unique server configuration for a particular project, create a duplicate

configuration using the Copy button, and use the Copy Servers wizard to edit it to your

needs.

Be aware that this automatic updating of projects with the latest server settings can

occur only with server configurations modified in JBuilder 9 or higher. If you attempt to

transfer server libraries from a previous JBuilder version, your projects won’t be

updated with them. You can still tell JBuilder to update the project manually:

1Right-click the project node of the project you want to update in the project pane and

choose Properties.

2Select the Servers page.

3Click the ellipsis (…) button next to your selected single server or the separate

service servers and make your changes.

4Click OK to close the dialog box.

28 Developing Applications for J2EE Servers

Updating from an earlier version of JBuilder

Previous versions of JBuilder supported an older module format. Your old modules will

be automatically converted to the new module format in JBuilder X. Once the

conversion has taken place, you will not be able to share modules between JBuilder X

and above and an earlier version of JBuilder.

Chapter 5: Using JBuilder with Borland servers 29

Chapter

Chapter 5Using JBuilder with Borland servers

This chapter explains how to set up and use Borland servers with JBuilder. JBuilder

supports Borland Enterprise Server AppServer Editions 5.2.1 and 6.0.1.

Configuring Borland servers in JBuilder

To configure JBuilder settings to target your preferred Borland server, you use the

Configure Servers dialog box (Enterprise|Configure Servers). See the instructions

below for either the Borland Enterprise Server AppServer Edition 6.0 or the Borland

Enterprise Server AppServer Edition 5.2.1.

Borland Enterprise Server AppServer Edition 6.0

To configure JBuilder settings to target Borland Enterprise Server AppServer

Edition 6.0,

1Choose Enterprise|Configure Servers to display the Configure Servers dialog box.

2Select Borland Enterprise Server AppServer Edition 6.0 from the User Home folder

in the left pane.

The right side of the dialog box displays the default settings for the server. The

General page has fields that all servers have in common, while the Custom page

has fields that are specific to the selected server. In some cases, modifying a

Custom setting will update a setting on the General page.

3Select the Enable Server option at the top of the dialog box.

Checking this option enables the fields for the selected application server. You won’t

be able to edit any fields until it is checked. The Enable Server check box also

determines whether this server will appear in the list of servers when you select a

server for your project using Project|Project Properties|Servers.

■Check the General tab to view and change (if required) default directories and

parameter settings for the server. If JBuilder’s default settings are not

appropriate, edit any of the settings as needed. To change settings, click the

ellipsis (…) button next to the field and make your changes.

30 Developing Applications for J2EE Servers

Configuring Borland servers in JBuilder

■Home Directory: The directory where Borland Enterprise Server AppServer

Edition 6.0 is installed. The default is Borland/BDP. If the default directory is not

accurate, use the ellipsis (…) button to select the correct directory.

■Native Executable Launcher: The native executable used to run this server. The

default is partition.exe in the Home Directory’s bin folder.

■VM Parameters: The parameters you want to pass to the virtual machine.

■Server Parameters: The parameters you want to pass to the server.

■Working Directory: The name and location of a working directory.

The General tab will look similar to this:

4Click the Custom tab to view and change (if required) fields unique to the server.

Change or fill in these fields:

■JDK Installation Directory: The directory where the JDK version required by the

server is located. JBuilder fills this field in automatically, depending on the value

you specified for the Home Directory on the General page. For the Borland

Enterprise Server AppServer Edition 6.0, this is the jdk/1.4.2 folder. Note that

your project will automatically be updated to use JDK 1.4.2.

■Server Name: The identifier of your machine.

■Configuration Name: The name of the configuration that manages the partition.

For more information see “Configurations, partitions, partition services, and J2EE

APIs” on page 34.

■Partition Name: The name of the partition in which the module is run. For more

information see “Configurations, partitions, partition services, and J2EE APIs” on

page 34.

■Add A Management Agent Item To The Enterprise Menu: Adds a Management

Agent item to the JBuilder Enterprise menu, so you can start the Management

Agent quickly from within JBuilder IDE.

■Server Realm: The realm of the server. For more information about the server

realm, see your Borland Enterprise Server documentation.

Chapter 5: Using JBuilder with Borland servers 31

Configuring Borland servers in JBuilder

■User Name: The name you use to identify yourself to the server. The default

value is admin.

■User Password: The password you use to identify yourself to the server. The

default fault is admin.

■Advanced Settings: Click this button to display the Advanced Settings dialog box.

Use this dialog box to change the number of the port used by the Management

Agent and to select the Use Security option. The management port is used in

JBuilder to detect the server during startup and deployment. Change the

management port only if you are deploying to a remote server with a

management port that is different from the default. When you change the port

number, ensure that you entered the correct port number as configured in the

server, as the server won’t start up without the correct port number. The port and

security settings you choose must match the settings of your server. JBuilder

updates the values in this dialog box whenever the Home Directory changes. The

values are read from the Borland Enterprise Server property files. Changing the

port number while you have the Management Agent started in JBuilder

automatically shuts down the Management Agent.

The Custom tab will look similar to this:

Borland Enterprise Server AppServer Edition 5.2.1

To configure JBuilder settings to target Borland Enterprise Server AppServer

Edition 5.2.1,

1Choose Enterprise|Configure Servers to display the Configure Servers dialog box.

2Select Borland Enterprise Server AppServer Edition 5.2.1 from the User Home

folder in the left pane.

The right side of the dialog box displays the default settings for the selected server.

The General page has fields that all servers have in common, while the Custom

page has fields that are specific to the selected server. In some cases, modifying a

Custom setting will update a setting on the General page.

32 Developing Applications for J2EE Servers

Configuring Borland servers in JBuilder

3Select the Enable Server option at the top of the dialog box.

Checking this option enables the fields for the selected application server. You won’t

be able to edit any fields until it is checked. The Enable Server check box also

determines whether this server will appear in the list of servers when you select a

server for your project using Project|Project Properties|Servers.

4Check the General tab to view and change (if required) default directories and

parameter settings for the server. If JBuilder’s default settings are not appropriate,

edit any of the settings as needed. To change settings, click the ellipsis (…) button

next to the field and make your changes.

■Home Directory: The directory where Borland Enterprise Server AppServer

Edition 5.2.1 is installed. The default is BES. If the default directory is not

accurate, use the ellipsis (…) button to select the correct directory.

■Native Executable Launcher: The native executable used to run this partition.

The default is partition.exe in the Home Directory’s bin folder.

■VM Parameters: The parameters you want to pass to the virtual machine.

■Server Parameters: The parameters you want to pass to the server. The default

is -partition jbuilder -server <server_name>.

■Working Directory: The name and location of a working directory.

The General tab will look similar to this:

5Click the Custom tab to view and change (if required) fields unique to the server.

Change or fill in these fields:

■JDK Installation Directory: The directory where the JDK version required by the

server is located. JBuilder fills this field in automatically, depending on the value

you specified for the Home Directory on the General page. For the Borland

Enterprise AppServer Edition 5.2.1, the directory is jdk/jdk1.4.1 directory in the

Home Directory. Note that this version of the Borland Enterprise Server can use

either JDK 1.3 or JDK 1.4.

■Server Name: The name of the server you are configuring. By default, JBuilder

specifies the identifier of your machine.

Chapter 5: Using JBuilder with Borland servers 33

Configuring Borland servers in JBuilder

■Partition Name: The name of the partition in which the server is run. For more

information about partitions, see “Configurations, partitions, partition services,

and J2EE APIs” on page 34.

■Add A Management Agent Item To The Enterprise Menu: Adds a Management

Agent item to the JBuilder Enterprise menu, so you can start the Management

Agent quickly from within JBuilder IDE.

■Add A SonicMQ Broker Agent Item To The Enterprise Menu: Adds the SonicMQ

Broker Agent item to the JBuilder Enterprise menu, so you can start the SonicMQ

Broker Agent quickly from within JBuilder IDE.

■Server Realm: The realm of the server. For more information about the server

realm, see your Borland Enterprise Server documentation.

■User Name: The name you use to identify yourself to the server. The default

value is admin.

■User Password: The password you use to identify yourself to the server. The

default fault is admin.

■Advanced Settings: Click this button to display the Advanced Settings dialog box.

Use this dialog box to change the number of the port used by the Management

Agent and to select the Use Security option. The management port is used in

JBuilder to detect the server during startup and deployment. Change the

management port only if you are deploying to a remote server with a

management port that is different from the default. When you change the port

number, please ensure that you entered the correct port number as configured in

the server, as the server won’t start up without the correct port number. The port

and security settings you choose must match the settings of your server. JBuilder

updates the values in this dialog box whenever the Home Directory changes. The

values are read from the Borland Enterprise Server property files. Changing the

port number while you have the Management Agent started in JBuilder

automatically shuts down the Management Agent.

The Custom tab will look similar to this:

34 Developing Applications for J2EE Servers

Making the ORB available to JBuilder

You use the CORBA node of the Enterprise Setup dialog box (Enterprise|Enterprise

Setup) to set up the Borland Enterprise Server for use with VisiBroker. For Borland

Enterprise Server AppServer Editions 6.0 and 5.2.1, the server will create its own

VisiBroker configuration called “VisiBroker <server name and version>.” The default

VisiBroker configuration won’t be changed.

You also use this dialog box to set the VisiBroker Smart Agent port to a unique number.

All client/server communication takes through the Smart Agent port. To start the Smart

Agent from the Tools menu, check the Add The VisiBroker Smart Agent Item To The

Tools Menu option. This option is selected by default. The CORBA node of the

Enterprise Setup dialog box looks like this:

To make the ORB available to JBuilder, you must start the VisiBroker Smart Agent with

the Enterprise|VisiBroker Smart Agent command. This handles the initial bootstrap

issues such as how the client locates the naming service and so on.

For Borland Enterprise Server AppServer Edition 5.2.1/6.0: If you choose

Enterprise|Borland Enterprise Server Management Agent, the VisiBroker Smart Agent

is started as part of the process. When you are working with the Borland Enterprise

Server AppServer Edition 5.2.1/6.0, you must start the Borland Enterprise Server

Management Agent instead of the VisiBroker Smart Agent. If you don’t start it, it is

automatically started for you when you start the server within JBuilder. Note that

starting the server automatically might take longer because the server searches for any

running agents. The most efficient way to start the Management Agent is to start it

yourself.

For more information on setting up the ORB for use within JBuilder, see “Setting up

JBuilder for CORBA applications” on page 47.

Configurations, partitions, partition services, and J2EE APIs

The architecture of the Borland Enterprise Server AppServer Edition 6.0 and 5.2.1

varies significantly. The Borland Enterprise Server AppServer Edition 6.0 introduces

the concept of management hubs and configurations. A management hub, also known

as the server control unit, controls, by server (or machine identifier), one or more

configurations. A configuration, in turn, manages one or more running partitions, or

processes. A configuration is based on an XML configuration file that resides in the

configuration’s root directory. This file determines the order of partition startup. A

configuration can have multiple partitions. Because each partition is a separate

process, an application’s functions can be distributed across multiple processes.

In the Borland Enterprise Server AppServer Edition 5.2.1, a server, also a machine

identifier, manages a partition. A server can also have multiple partitions. And, as with

Chapter 5: Using JBuilder with Borland servers 35

Configurations, partitions, partition services, and J2EE APIs

Borland Enterprise Server AppServer Edition 6.0, because each partition is a separate

process, an application’s functions can be distributed across multiple processes. For

either edition, when you use the Configure Servers dialog box to configure the server,

all these pieces are seamlessly set up for use in JBuilder.

For more information on the Borland Enterprise Server architecture, refer to the

documentation, available from the Help menu of the Borland Management Console.

In both editions, partitions provide containers and services for hosting your

applications. Any or all of a partition’s containers and services can be enabled or

disabled. Additionally, a partition can be cloned (copied) on the same configuration or

server or on another enterprise configuration or server located on the same local area

network. Cloning a partition can save significant time in the deployment process

because it not only copies all of the deployed modules, but also copies all the

associated service configurations settings which can require a considerable amount of

time and effort to complete.

Application components are hosted in either the web container or EJB container, or

simply in the partition itself (in the case of connectors). You can deploy application

EARs or smaller archives to partitions. The partitions are “smart” and will place your

application components in the proper containers. Since you may create as many

partitions as you wish, you can also have as many container instances as you wish.

Borland provides up to two different containers per partition instance:

■Web container (Tomcat 4.x or 5.0): for hosting JSPs and servlets, and

■EJB container (Borland): for hosting EJB components

Each partition also provides Partition Services and J2EE APIs as Partition Services.

These services and APIs are:

■Naming Service: In Borland Enterprise Server, the Naming Service is managed by

the VisiBroker ORB.

■JDataStore: Borland’s all-Java database.

■JDBC: For getting connections to and modeling data from databases.

■Java Mail: A Java email service.

■JTA: The Java transactional API.

■JAXP: The Java API for XML parsing.

■JNDI: The Java Naming and Directory interface.

■RMI-IIOP: Remote method invocation (RMI) carried out via internet inter-ORB

protocol (IIOP).

JBuilder, by default, uses a partition named jbpartition and a configuration named

jbuilder as a deployment target for Borland Enterprise Server AppServer Edition 6.0.

For Borland Enterprise Server AppServer Edition 5.2.1, the partition name is jbuilder.

If the configuration or partition doesn’t exist, one will be created for you automatically.

For both editions, the default partition shares the same port number with Tomcat and

JDataStore services. Additionally, in both editions, the server name is the same as the

machine identifier.

You can start multiple partitions using multiple JBuilder run configurations. To create

multiple run configurations, follow these steps:

1Choose Run|Configurations, then click New.

2Change the Run Type to Server. The displayed server is the server selected for the

project in Project Properties|Server.

3In the Category tree, select Server|Command Line.

36 Developing Applications for J2EE Servers

Configurations, partitions, partition services, and J2EE APIs

4For Borland Enterprise Server 6.0, change the Partition And Configuration Name to

the one you want to use. The Command Line page looks like this:

For Borland Enterprise Server 5.2.1, edit the Server Command Line parameters and

change the partition name to the one you want to use, as show in the following

figure:

5Click OK to close the New Runtime Configuration dialog box and save the

configuration.

6Repeat these steps to create additional run configurations to run other partitions.

Before starting up the partition, make sure you have configured unique port numbers

for Tomcat and JDataStore services.

Also ensure that you have the naming service enabled for only one of the partitions to

avoid naming service conflicts. To disable the naming service for a partition, edit the

Chapter 5: Using JBuilder with Borland servers 37

Configurations, partitions, partition services, and J2EE APIs

run configuration for the partition (Edit Runtime Configuration dialog box) and uncheck

the naming service option, as shown in the following figure:

Changing the management port

The management agent manages all partitions. The default management port, set on

the Advanced Settings dialog box for both Borland Enterprise Server AppServer

Editions 6.0 and 5.2.1, is 42424. You can change the management port used by

JBuilder, or the one used by the server.

To change the port used by JBuilder,

1Choose Enterprise|Configure Servers and chose Borland Enterprise Server

AppServer Edition 6.0 or 5.2.1 from the User Home Folder on the left.

2Click the Custom tab, then the Advanced Settings button.

3Change the port in the Management Port field, as shown in the following figure:

4Click OK two times.

To change the management port used by the server,

1Open the Borland Management Console.

2Double-click Installations.

3For Borland Enterprise Server 6.0, choose Wizards|Configure Agents. For Borland

Enterprise Server 5.2.1, right-click the server you want to change the port for.

4Select Update Ports.

5Use the Port Configuration wizard to change the Management Port number. The

User Port value is equal to the Smart Agent Port in JBuilder.

After you change the management port, the management agent will shutdown if it was

started in JBuilder.

38 Developing Applications for J2EE Servers

Starting the configuration or server

Before any server related actions (server startup, deployment, and so on) are

performed, you must start the management agent with Enterprise|Borland Enterprise

Server Management Agent (use the version of this command that matches the version

of the Borland Enterprise Server AppServer Edition your project is targeted for.). For

the Borland Enterprise Server 6.0, this will start the management hub. For Borland

Enterprise Server 5.2.1, this starts the server.

For both editions, after the management agent has started up, you can launch the

partition by right-clicking the EJB or web module in the project pane and selecting Run

Using Defaults. You can also create a Server run configuration and run the project

using that configuration.

Running the partition in JBuilder will

■Create the partition (and configuration for Borland Enterprise Server 6.0), if not

already present. The partition name (and the configuration name for Borland

Enterprise Server 6.0) used in this step is derived from the run configuration used to

start up the server. If you are starting the configuration or server using the default

configuration, the partition name as configured in the application server properties

will be used.

■Deploy any resources defined in jndi-definitions.xml (if present) to the root of the

partition directory. For the Borland Enterprise Server AppServer Edition 6.0, this

directory is: PARTITION_NAME\dars\jbuilder.dar. For Borland Enterprise Server 6.0

only, the jndi-definitions.xml file is packaged into a .dar file and deployed. For the

Borland Enterprise Server AppServer Edition 5.2.1, it is: APPSERVER_HOME\var\

servers\SERVER_NAME\partitions\PARTITION_NAME\.

This file will be created if your project contains an EJB 2.0 module with data

sources/messaging resources defined.

Note This action can be turned off by unchecking the Deploy jndi-definitions.xml option in

the Deployment EJBs Services properties on the Server node of the Project

Properties dialog box.

■Copy selected libraries to the partition’s lib directory. All archives in this directory

will be added to the partition’s classpath when the partition is started up.

The directory on the server for Borland Enterprise Server AppServer Edition 6.0 is

APPSERVER_HOME\var\domains\base\configurations\CONFIGURATION_NAME\mos\

PARTITION_NAME\lib. For the Borland Enterprise Server AppServer Edition 5.2.1, the

directory is APPSERVER_HOME\var\servers\SERVER_NAME\partitions\PARTITION_NAME\lib.

Chapter 5: Using JBuilder with Borland servers 39

Starting the configuration or server

The libraries to be copied can be set with the Libraries To Deploy At Runtime list on

the Edit Runtime Configuration dialog box for the server run configuration:

■Remove any archives deployed to the partition, if this option is selected. This can be

set from the Archives Server category on the Edit Runtime Configuration dialog box

for the server run configuration. If you want to have a clean partition, select the

Remove Archives Already Deployed To Server option.

■Deploy archives if selected. By default all deployable archives in the project are

selected. To change this, click the Archives Server category in the Server run

configuration (Edit Runtime Configuration dialog box) and unselect any archives that

you do not wish to deploy.

■Start the partition. When partition startup is complete, you should see the partitions

listed in the message pane for Borland Enterprise Server AppServer Edition 6.0 or

the message ‘Partition <PARTITION_NAME> has been started’ for Borland

Enterprise Server AppServer Edition 5.2.1. Archives deployed at startup should be

loaded and accessible.

40 Developing Applications for J2EE Servers

Remote deploying

Note By default, all services associated with a partition are started. This could cause the

partition to take a longer time to start. To reduce startup time, uncheck the services that

you don’t require in the Server run configuration.

Remote deploying

To prepare to remote deploy EJBs, WARs, and EAR modules for the Borland

Enterprise Server AppServer Edition 6.0, follow these steps.

1Choose Enterprise|Configure Servers.

2Select Borland Enterprise Server AppServer Edition 6.0 from the left side of the

dialog box.

3Click the Custom tab and set the Server, Configuration, and Partition names to

match that of the remote server.

4Click the Advanced Settings button and make sure the Management Port matches

your server configuration.

5Click OK two times.

6Choose Enterprise|Enterprise Setup.

7Select the CORBA node to display the CORBA page, and set the Smart Agent Port

to match that of your server configuration.

8Click OK.

To prepare to remote deploy EJBs, WARs, and EAR modules for the Borland

Enterprise Server AppServer Edition 5.2.1, follow these steps.

1Choose Enterprise|Configure Servers.

2Select Borland Enterprise AppServer Edition 5.2.1 from the left side of the dialog

box.

3Click the Custom tab and set the Server and Partition names to match that of the

remote server.

4Click Advanced Settings and make sure the Management Port matches your server

configuration.

5Click OK two times.

6Choose Enterprise|Enterprise Setup.

7Select the CORBA node to display the CORBA page, and set the Smart Agent Port

to match that of your server configuration.

8Click OK.

Now you are ready to deploy. There are two ways to deploy EJBs, WARs, and EAR

modules using JBuilder:

■Deploying to the server using the Borland Enterprise Server Deployment Wizard

(Enterprise|Server Deployment). This is a Borland Enterprise Server tool and

requires that the management agent is running. On the first page of the wizard,

select the modules to deploy. The wizard then detects all partitions on the server,

even if they have not been started. Select the appropriate partition from the list and

click Finish to deploy the archive. If the partition has already been started, restart the

partition to access the deployed archive.

■Deploying to the server using the context menu option on any deployable node.

Right-click the deployable node to see the Deploy commands. Choose Deploy. You

can also select multiple deployable nodes, right-click them, and use the context

menu that appears to deploy more than one module.

Chapter 5: Using JBuilder with Borland servers 41

Remote debugging

Before you can debug your application remotely, you need to configure the partition.

You can do this before you start the server or while the server and partition are already

running. See these sections for more information:

■“Preparing to remote debug partitions that are not managed in JBuilder” on page 41

■“Preparing to remote debug partitions that are managed in JBuilder” on page 41

■“Preparing to remote debug before the Borland Enterprise Server AppServer Edition

5.2.1 is running” on page 42

■“Preparing to remote debug when the Borland Enterprise Server AppServer Edition

5.2.1 is already running” on page 42

Once the configuration is complete and the server and partition are started, follow the

instructions in “Remote debugging in JBuilder” on page 43.

Remote debugging for Borland Enterprise Server 6.0

Preparing to remote debug partitions that are not managed in JBuilder

To prepare to remote debug partitions that are not managed in JBuilder,

1Start the Borland Management Console.

2Start the server.

3Locate the partition you wish to debug.

4Right-click the partition and choose Properties.

5Select the Partition Settings tab.

6Check the Enable JPDA Remote Debugging option.

7Set the transport address field to 3999.

8Uncheck the Suspend Partition Until Debugger Attaches option.

9Click OK.

Preparing to remote debug partitions that are managed in JBuilder

To prepare to remote debug partitions that are managed in JBuilder, you have two

options:

Starting the server/configuration/partition outside of JBuilder

1Shut down the server.

2Open the file <APPSERVER_HOME>/var/domains/base/configurations/configuration.xml.

3Look for the JPDA element and edit attribute values as follows:

enable-jpda-debug="true"

jpda-transport-address="3999"

jpda-suspend="false"

4Start the server/configuration/partition outside of JBuilder.

Starting the management agent/partition in JBuilder

1Shut down the server.

2Open the file <APPSERVER_HOME>/var/domains/base/configurations/configuration.xml.

42 Developing Applications for J2EE Servers

Remote debugging

3Look for the JPDA element and edit attribute values as follows:

enable-jpda-debug="true"

jpda-transport-address="3999"

jpda-suspend="false"

4Choose Run|Configurations, select the server run configuration, and click the Edit

button.

5Set the following server parameters: -jpda:address=3999

6Start the management agent/partition in JBuilder.

Remote debugging for Borland Enterprise Server 5.2.1

Preparing to remote debug before the Borland Enterprise Server AppServer

Edition 5.2.1 is running

To set up for remote debugging before you start the Borland Enterprise Server

AppServer Edition 5.2.1,

1Start the Borland Management Console.

2Click the Installations button.

3Locate the server you will start. Expand the node and locate the partition you wish to

debug in JBuilder.

4Click the partition node in the structure pane.

5Search for and set the debug parameters as follows in the content pane (set the

values that are in bold-faced type):

partition.enable_jpda_debug=true

partition.jpda.transport_address=3999

partition.jpda.suspend=false

6Click Apply Changes.

Preparing to remote debug when the Borland Enterprise Server AppServer

Edition 5.2.1 is already running

To set up for remote debugging when the Borland Enterprise Server AppServer Edition

5.2.1 is already running,

1Start the Borland Management Console.

2Click the Servers button.

3Expand the Enterprise Servers node and locate the partition you want to debug.

4Right-click and select Configure.

5Choose the JPDA tab.

6Check the Enable JPDA Remote Debugging option.

7Set the transport address field to 3999.

8Uncheck the Suspend Partition Until Debugger Attaches option.

9Click Apply Changes.

Chapter 5: Using JBuilder with Borland servers 43

Web module workarounds

Remote debugging in JBuilder

Once either edition of the Borland Enterprise Server AppServer and the partition have

been started, follow these steps from within JBuilder:

1In the project from which you want to launch the remote debug session, choose

Run|Configurations. If you have not yet created a Server type run configuration,

click New. In the New Runtime Configuration dialog box, set the Type to Server. If

you have already created a Server run configuration, select it and choose Edit.

2Select the Debug|Remote node.

3Check the Enable Remote Debugging option.

4Select the Attach option.

5Enter the name of the machine on which the server is running in the Host Name

field.

6Make sure the Transport Type is set to dt_socket and the Address is set to 3999.

The dialog box will look similar to this:

7Click OK to close the dialog box.

8Set a breakpoint in the process you want to debug.

9Deploy that process to the running partition.

10 Click the down arrow next to the Debug Project button on the toolbar and select the

Server configuration you just created or edited. The debugger launches, attaches to

the partition running remotely, and stops at the breakpoint.

Web module workarounds

The default application server install includes ROOT.war, which contains the default

context. If you deploy an EAR that contains a default context, you must delete ROOT.war

(or rename its extension) so that it does not load and cause a conflict. If deploying

WARs (with the container classloader policy), the resulting WAR is automatically

copied to the partition as ROOT.war, in which case there is no conflict. Please note that it

is the <context-root>!ROOT!</context-root> element in the web-borland.xml file that

designates the context as root, not the file name.

44 Developing Applications for J2EE Servers

Displaying the Borland Management Console in JBuilder

If you are working on a named context but have the root context in an already deployed

archive, the internal web browser in JBuilder will attempt to load once that archive is

loaded by the container, because the root context can potentially match any URL.

You’ll then probably get a “Document not found” error. To prevent this, remove

ROOT.war if you’re not using it or overwriting it.

Displaying the Borland Management Console in JBuilder

You can display the Borland Management Console in JBuilder. Choose View|Panes|

BES Console.

International issues

The Borland Enterprise Server AppServer Editions 6.0 and 5.2.1 do support Japanese

characters in the JNDI name.

Borland servers and JDataStore 7.0

The Borland Enterprise Servers 5.2.1 and 6.0 do not support JDataStore 7.0.1,

although JBuilder does. When you are running applications that access JDataStore

databases, be sure you are using the JDataStore 6.x or older file format and

JDataStore libraries that ship with the server. Databases created using JDataStore 7.0

cannot be used with Borland Enterprise Server 5.2.1 and 6.0.

Chapter 6: Using JBuilder’s CORBA tools 45

Chapter

Chapter 6Using JBuilder’s CORBA tools

This chapter explains the CORBA (Common Object Request Broker Architecture) tools

available in JBuilder, including the VisiBroker ORB and IDL compilers.

The Common Object Request Broker Architecture (CORBA) allows distributed

applications to interoperate (application to application communication), regardless of

what language they are written in or where these applications reside.

The CORBA specification was adopted by the Object Management Group to address

the complexity and high cost of developing distributed object applications. CORBA

uses an object-oriented approach for creating software components that can be reused

and shared between applications. Each object encapsulates the details of its inner

workings and presents a well defined interface, which reduces application complexity.

The cost of developing applications is reduced, because once an object is

implemented and tested, it can be used over and over again.

The Object Request Broker (ORB) connects a client application with the objects it

wants to use. The client program does not need to know whether the object

implementation it is in communication with resides on the same computer or is located

on a remote computer somewhere on the network. The client program only needs to

know the object’s name and understand how to use the object’s interface. The ORB

takes care of the details of locating the object, routing the request, and returning the

result.

Note The ORB itself is not a separate process. It is a collection of libraries and network

resources that integrates within end-user applications, and allows your client

applications to locate and use objects.

JBuilder supports the VisiBroker ORB and the OrbixWeb ORB. JBuilder also provides

tools to configure other third-party ORBs.

How JBuilder and the VisiBroker ORB work together

The VisiBroker ORB provides a complete CORBA ORB runtime and supporting

development environment for building, deploying, and managing distributed Java

applications that are open, flexible, and inter-operable. The VisiBroker ORB is part of

the Borland Enterprise Server. Objects built with the VisiBroker ORB are easily

accessed by Web-based applications that communicate using OMG’s Internet Inter-

ORB Protocol (IIOP) standard for communication between distributed objects through

46 Developing Applications for J2EE Servers

How JBuilder and the VisiBroker ORB work together

the Internet or through local intranets. The VisiBroker ORB has a native

implementation of IIOP to ensure high-performance and inter-operability.

The VisiBroker ORB incorporates the following compilers for working in a Java

environment:

■java2iiop

The java2iiop compiler allows you to stay in an all-Java environment. The java2iiop

compiler takes your Java interfaces and generates IIOP-compliant stubs and

skeletons. Part of the advantage of using the java2iiop compiler is that, through the

use of extensible structs, you can pass Java serialized objects by value.

■java2idl

The java2idl compiler turns your Java code into IDL, allowing you to generate client

stubs in the programming language of your choice. In addition, because this

compiler maps your Java interfaces to IDL, you can re-implement Java objects in

another programming language that supports the same IDL.

When you develop distributed applications with JBuilder and the VisiBroker ORB, you

must first identify the objects required by the application. You will then usually follow

these steps:

1Write a specification for each object using the IDL wizard to generate the Interface

Definition Language (IDL) file. IDL is the language an implementer uses to specify

the operations an object will provide and how they should be invoked.

2Use the IDL compiler to generate the client stub code and server Portable Object

Adapter (POA) servant code.

3Write the client program code.

4Write the server object code.

5Compile the client and server code.

6Start the server.

7Run the client program.

For in-depth information on using the VisiBroker ORB to create distributed applications,

see the VisiBroker documentation in the doc directory of your Borland Enterprise Server

installation.

For more information about Common Object Request Broker Architecture (CORBA),

some useful links are:

■http://www.borland.com/books — Books on Borland products and related

technologies

■“A White Paper: Java, RMI, and CORBA” at http://www.omg.org/news/whitepapers/

wpjava.htm

■CORBA/IIOP Specification in Introduction to OMG’s Specifications at

http://www.omg.org/gettingstarted/specintro.htm

■CORBA Basics at http://www.omg.org/gettingstarted/corbafaq.htm

RMI

Another way to invoke methods on remote Java objects is to use Remote Method

Invocation (RMI). The Borland Enterprise Server provides capabilities equivalent to

RMI, but, in addition, allows you to create Java objects that communicate with all other

objects that are CORBA compliant even if they are not written in Java. For an example

of a Java interface that describes an RMI remote interface, see the sample file

Account.java in the examples/vbe/rmi-iiop/Bank directory of your Borland Enterprise

Server installation.

Chapter 6: Using JBuilder’s CORBA tools 47

Setting up JBuilder for CORBA applications

This section explains how to set up JBuilder with the VisiBroker ORB or OrbixWeb so

that you can create, run, and deploy CORBA applications. You can also configure

other, third-party ORBs. More information on the VisiBroker ORB is available in the doc

directory of your Borland Enterprise Server installation. Consult the OrbixWeb

documentation for information on particular features of that ORB.

Configuring VisiBroker when the Borland Enterprise Server

is installed

Follow the steps in this section to set up JBuilder for use with VisiBroker when the

Borland Enterprise Server AppServer Edition 6.0 is already installed, configured and

the target server for your project. Note that the server creates its own VisiBroker

configuration. For information on configuring Borland Enterprise Server, see Chapter 5,

“Using JBuilder with Borland servers.”

To configure VisiBroker when the Borland Enterprise Server is installed,

1Choose Enterprise|Enterprise Setup to display the Enterprise Setup dialog box.

Select the CORBA page. The parameters in this dialog box allow JBuilder to see the

ORB.

2Select the VisiBroker (Borland Enterprise Server AppServer Edition 6.0) option from

the Configuration drop-down list.

The Enterprise Setup dialog box will look similar to this:

3Click OK to close the dialog box. You do not have to complete other configuration

steps; JBuilder is now configured for use with VisiBroker.

4Click OK to save the configuration.

Important In the runtime configuration for your CORBA application, you need to add the following

parameters to the VM Parameters field in the Edit Runtime Configuration dialog box

(Run|Configurations|Edit):

-Dvbroker.agent.port=14000

-Dborland.enterprise.licenseDir=C:/<BES_install>/var

-Dborland.enterprise.licenseDefaultDir=C:/<BES_install>/license

You’ve now completed setting up your system to use the VisiBroker version installed

with the Borland Enterprise Server AppServer Edition 6.0. Before running your

application, choose Tools|VisiBroker Smart Agent to start the Smart Agent. (Note that it

is also automatically started when you start the Management Agent with the Enterprise|

Borland Enterprise Server Management Agent command.)

48 Developing Applications for J2EE Servers

Setting up JBuilder for CORBA applications

Configuring VisiBroker stand-alone

Follow the steps in this section to set up JBuilder for use with VisiBroker stand-alone;

that is, without targeting your project for the Borland Enterprise Server AppServer

Edition 6.0.

To configure VisiBroker stand-alone,

1Choose Enterprise|Enterprise Setup to display the Enterprise Setup dialog box.

Select the CORBA page. The parameters in this dialog box allow JBuilder to see the

ORB.

2Select the VisiBroker option from the Configuration drop-down list.

3Click the Edit button to display the Edit Configuration dialog box.

4The Path For ORB Tools field allows JBuilder to access ORB tools. Click the ellipsis

(…) button next to the Path For ORB Tools field to browse to the directory

containing the ORB tools. Point to the directory that contains the osagent.exe file.

This is the bin directory of your Borland Enterprise Server installation.

Chapter 6: Using JBuilder’s CORBA tools 49

Setting up JBuilder for CORBA applications

5The Library For Projects field defines the library location of the ORB tools. To define

the library location, click the ellipsis (…) button next to the Library For Projects field.

This displays the Select A Different Library dialog box.

The library is necessary for compiling the generated stubs and skeletons and for

executing an application. For VisiBroker, browse to the Borland Enterprise Server

6.0 Client library, then click OK two times.

6In the Enterprise Setup dialog box, leave the Apply This Configuration To The

Current Project option selected in order to set this ORB configuration for the current

project, as well as the default project.

7Set the Make This Configuration’s ORB The Default For The Java VM option to use

the selected ORB as the default ORB for the Java VM.

8Select the Add A VisiBroker Smart Agent Item To The Tools Menu option to enable

the Smart Agent to run as a JBuilder service during development. This option will be

disabled if the Smart Agent is not necessary.

9Select a port on which to run the Smart Agent. The default port of 14000 will work on

most systems.

Note When running the project, you can use a JBuilder macro in the VM Parameters field

on the Edit Runtime Configuration dialog box for the application. This macro allows

the project to be used on another machine where the Smart Agent is configured for

a different port. The syntax is:

-Dvbroker.agent.port=($SmartAgentPort)

10 Click OK to save the configuration.

You also need to pass options to the IDL compiler.

To pass options to the IDL compiler when configuring VisiBroker stand-alone,

1Choose Project|Project Properties|Build|IDL to display the IDL Build page, which will

look similar to this:

50 Developing Applications for J2EE Servers

Setting up JBuilder for CORBA applications

2Make sure VisiBroker is selected as your IDL compiler.

3Enter the following options into the Additional Options field:

-VBJprop borland enterprise.licenseDir=<visibroker license directory>

-VBJjavavm<jdk1.4.1 java or javaw path>

The license directory is <BES_install>\var\servers\SERVER_NAME\adm. The <server

directory> is same as the server name assigned when you configured the server

using Enterprise|Configure Servers. You can find the server name on the Custom

page of the Configure Servers dialog box.

4Click OK to close the Project Properties dialog box.

You must still perform one step: starting the VisiBroker Smart Agent. This handles the

initial bootstrap issues such as how the client locates the naming service and so on. To

start the Smart Agent, choose Tools|VisiBroker Smart Agent.

You’ve now completed setting up your system to use the JBuilder CORBA features.

Configuring the OrbixWeb ORB

Follow the steps in this section to set up JBuilder for use with the OrbixWeb ORB.

To configure the OrbixWeb ORB,

1Choose Enterprise|Enterprise Setup to display the Enterprise Setup dialog box.

Select the CORBA page. The parameters in this dialog box allow JBuilder to see the

ORB.

2Select the OrbixWeb option from the Configuration drop-down list.

3Click the Edit button to display the Edit Configuration dialog box.

Chapter 6: Using JBuilder’s CORBA tools 51

Setting up JBuilder for CORBA applications

4The Path For ORB Tools field allows JBuilder to access ORB tools. Click the ellipsis

(…) button next to the Path For ORB Tools field to browse to the directory

containing the ORB tools.

5The Library For Projects field defines the library location of the ORB tools. To define

the library location, click the ellipsis (…) button next to the Library For Projects field.

This displays the Select A Different Library dialog box. The library is necessary for

compiling the generated stubs and skeletons and for executing an application.

Choose the library and click OK two times.

6In the Enterprise Setup dialog box, leave the Apply This Configuration To The

Current Project option selected if this ORB configuration should be applied to the

current project as well as the default project.

7Set the Make This Configuration’s ORB The Default For The Java VM option to use

the selected ORB as the default ORB for the Java VM.

8Click OK to save the configuration.

Adding a new configuration

Follow the steps in this section to create a new configuration for a third-party ORB.

To configure a third-party ORB,

1Choose Enterprise|Enterprise Setup to display the Enterprise Setup dialog box.

Select the CORBA page. The parameters in this dialog box allow JBuilder to see the

ORB.

2Select the None option from the Configuration drop-down list, then click the New

button. The New Configuration dialog box is displayed.

3Enter a name for the configuration in the Name For This Configuration field.

4Enter the path for the ORB tools in the Path For ORB Tools field. Click the ellipsis

(…) button to browse to the directory containing the ORB tools.

5Click the ellipsis (…) button next to the Library For Projects field to display the

Select A Different Library dialog box. You use this dialog box to browse to the library

52 Developing Applications for J2EE Servers

Setting and viewing ORB build properties

location of the ORB tools. The library is necessary for compiling the generated stubs

and skeletons and for executing an application.

aTo add a library that is not displayed in the Select A Different Library dialog box,

click the New button.

bIn the New Library wizard, enter a name for the new library in the Name field.

cSelect a location for the library: the JBuilder directory, the project directory, or

your home directory.

dClick Add to browse to the library (JAR) file.

eClick OK until you return to the New Configuration dialog.

6Enter the command for the IDL compiler in the IDL Compiler Command field.

7Enter the IDL compiler command option that specifies the output directory in the

Command Option For Output Directory field.

8Click OK to close the New Configuration dialog box.

9In the Enterprise Setup dialog box, leave the Apply This Configuration To The

Current Project option selected in order to set this ORB configuration for the current

project, as well as the default project.

10 Click OK to save the new configuration.

Setting and viewing ORB build properties

This section explains how to set and view build properties for the installed ORB.

Setting VisiBroker ORB properties

To set and view properties for the java2iiop and java2idl compilers in the JBuilder

development environment,

1Choose Project|Project Properties|Build|IDL. The IDL page is displayed.

Chapter 6: Using JBuilder’s CORBA tools 53

Setting and viewing ORB build properties

Make sure the IDL Compiler field is set to VisiBroker or VisiBroker (Borland

Enterprise Server AppServer Edition 6.0 and 5.2.1).

2Set the Generated Code Options as needed:

■In the Package field, enter the name of the package to generate code in. The

package name for definitions is prepended with the specified package name. If a

directory with the specified package name does not exist, it will be created. If the

package directory exists, its contents will be updated. Code is generated that

uses CORBA package resolution rules.

■In the Include Path field, enter the location where other files that are referenced

from IDL files reside. Click the ellipsis (…) button beside this field to open a dialog

box that lets you browse the directory structure for the location of the files.

■In the Additional Options field, enter any additional options for your IDL compiler,

as you would enter them when running the compiler from the command line.

■The Symbols Defined For Conditional IDL Compilation list displays symbols that

have been defined for conditional IDL compilation. Click the New button to

display the Define New Symbol dialog box where you can define a new

conditional symbol. To remove a symbol from the list, select it then choose the

Delete button.

3Choose the Paths node of the Project Properties dialog box. Make sure the

Required Libraries list includes the Borland Enterprise Server 6.0 Client.

4Click OK to close the Project Properties dialog box.

5Once you’ve created a Java interface file in your JBuilder project, right-click the file

in the project pane and choose Properties.

6On the Build|VisiBroker node, select the Generate IDL and Generate IIOP options.

The dialog box should look like this:

■Select the Java2IDL Generate IDL option to generate an Interface Definition

Language (IDL) file from a Java file or a class file. To support the distribution of

objects implemented in a variety of programming languages, an IDL file is used to

define the services offered by a particular distributed object.

■Enter any Java2IDL command line options in the Options field. See the Borland

Enterprise Server VisiBroker documentation for command line options.

■The Java2IIOP Generate IIOP Interface option generates an Internet InterORB

(Object Request Broker) Protocol (IIOP) compatible Java interface file from a

Java interface or class file. This is done by creating a new Java interface that

extends org.omg.Corba.object. This Java interface can be used to describe

CORBA interfaces in place of using an Interface Definition Language (IDL) file to

describe the interfaces. The IIOP protocol maintains a basic set of functionality to

ensure inter-operability between client applications and server-based objects in a

Common Object Request Broker Architecture (CORBA).

54 Developing Applications for J2EE Servers

Setting and viewing ORB build properties

■Set the Java2IIOP Strict Portable Code Generation (Java2IIOP) option to enable

generation of portable stubs, that is, stubs that contain code not specific to

VisiBroker.

■Set the Java2IIOP Generate Example Implementation option to enable

generation of example implementation code.

■Set the Java2IIOP Generate Tie Bindings option to enable generation of tie

classes.

■Set the Java2IIOP Generate Comments option to enable generation of

comments in the source code.

■Enter any Java2IIOP command line options in the Options field. See the Borland

Enterprise Server VisiBroker documentation for command line options.

7Click OK to close the dialog box.

Setting build properties for the OrbixWeb or other third-party

ORBs

To set and view properties for a configured ORB,

1Choose Project|Project Properties|Build|IDL. The IDL page is displayed.

Make sure the IDL Compiler field matches the ORB you selected in the Enterprise

Setup dialog box.

2Set the Generated Code Options as needed:

■In the Package field, enter the name of the package to generate code in. The

package name for definitions is prepended with the specified package name. If a

directory with the specified package name does not exist, it will be created. If the

package directory exists, its contents will be updated. code is generated that