REFERENCE:

EJB Deployment Expert for IBM WebSphere 3.5

You can use the EJB Deployment Expert to compile your EJBs and deploy them on WebSphere 3.5 server. This topic provides detailed information for the server-specific pages of the expert.

Process options

Add libraries, required for deployment, to the project Search/Classpath

EJB deployment requires a number of server specific libraries. Since diverse servers use specific versions of J2EE specification, they generally suggest their own libraries that cover J2EE specification for the particular server usage. Therefore, server specific library is normally added to the Classpath instead of Sun J2EE. Check this box to compile and deploy EJB or client program, and to make sure that you have all required libraries on your Classpath.

Verify/Correct EJB sources for compliance with WAS3.5 specification

This task verifies that the classes on the current diagram correspond to EJB specification supported by the destination server. Moreover, some servers have individual specification features. The primary objective of this task is to make sure that all the required classes exist on the diagram.

Note: The current diagram is used as the source of beans. Therefore, you have to open appropriate class or assembler diagram.

Compile classes from the selected diagram

Compiles the bean and packs it to a JAR file. New archive is stored in a temporary folder. Standard Sun tool (javac.exe and jar.exe) is used for compilation and packing.

Generate deployment descriptor

In addition to the descriptor generation, this task performs some spade-work for deployment:

Generate WLM jar for Bean(s)

Check this box to use WebSphere utility for automatic generation of additional classes for WorkLoad Management (WLM) support. See WebSphere InfoCenter documentation for details.

Hot Deploy (use "Start Weblogic Application Server 5.1" or start the server manually)

If you check this box, deployment will be executed. This step makes use of a bean already compiled and jarred. Therefore you have to use this step in conjunction with the others.

Warning: Be aware that all hot deployed beans will be lost after WebLogic termination. You will have to re-deploy necessary beans again. In order to deploy your beans permanently, you have to add certain lines to weblogic.property file manually.

Note: As a rule, it is strongly advised to compile classes, generate descriptiors and deploy the beans all together, because some tasks use the results of the previous tasks. For example, Hot Deploy task requires *.jar file to be prepared in a temporary folder.

Process Servlet(s)

Check this box to compile servlets, if they exist on the current diagram. Automatic server deployment is not provided. As of this writing, you have to deploy your servlets manually.

Stop and Remove Bean(s) and Servlet(s) before deployment

You are safe to skip this field, if you perform deployment for the first time. Otherwise you have to terminate and remove all servlets and beans destined for deployment during the current expert execution; otherwise it may cause problems.

Start Bean(s) and Servlet(s) after deployment

The servlets and beans do not start automatically after deployment . Check this option if you want them to launch.

Clear temp folder before start / Clear temp folder after finish

You can skip these options if you want to reuse temporary files.

Generate start and compile file for client

Together and WebSphere use different versions of JDK. Strange it may seem, WebSphere requires using IBM JDK for the client programs. Thus, we cannot make use of Together's internal tools and have no other way but to generate two batch files, one of them being destined to compile, and the other one to run the client program. Subsequently, you can start them separately from Together.

Generate simple JSP client

Check this box to generate a JSP client for the Enterprise Beans. Client is a set of interrelated JSP and HTML files, which can be viewed in any Internet browser. The intention of this client is to demonstrate access to remote EJB objects through the opened interfaces. The semantic information required for JSP client generation is taken from the active diagram of the current project. Due to the lack of information, it is impossible to create a client program ready for commercial use. That's why JSP client can be regarded as a universal testing facility.

Page "Common properties"

The fields on this page are quite self-explanatory. However, this section provides brief descriptions for some of them .

Folder for the generated JAR file

Specify location where the resulting JAR file will be stored and from where it will be loaded by WebSphere.

Short name of EJB JAR file

This name is assigned to the JAR file generated in Compile Classes task from the selected diagram. While preparing for deployment, an additional JAR file is created, whose name is based on the short name assigned here.

Page "Run-time deploy"

This page provides entries for the Hot deploy task and some other properties.

Admin Node Name

By default this name is equal to the local computer name and assigned automatically.

Dependent Classpath

Contents of this field must be equal to the appropriate property Administrating node at the WebSphere Advanced Administrative Console.

Application server name

Single WebSphere node can hold several virtual Application Servers. By default, only one is allocated. Its name is Default Server. Same name is used by default in Together's Deployment Expert. If you are going to use another application server, specify its name in this field. If the server with the specified name does not exist, it will be created.

Application Server Command Line Arguments

Contents of this field must be equal to the appropriate property of Application server at the WebSphere Advanced Administrative Console.

Application Server Classpath

Contents of this field must be equal to the appropriate property of Application server at the WebSphere Advanced Administrative Console.

EJB container name

Single WebSphere virtual Application Server can hold several EJB containers. By default, only one is allocated. Its name is Default Container. Same name is used by default in Together's EJB Deployment Expert. If you are going to use another container, specify its name in this field. If the container with the specified name does not exist, it will be created.

Data Source name

WebSphere server can contains several Data Sources. By default, only one is allocated. Its name is Default DataSource. Same name is used by default in Together's EJB Deployment Expert. If you are going to use another Data Source, specify its name in this field. If the Data Source with the sepcified name doesn't exist, it will not be created automatically. You have to create the Data Source manually before using it.

User ID / Password (only for CMP beans)

These fields are necessary to maintain container managed persistence. You can use user name and password assigned during WebSpere installation.

Create Table for CMP EJBs

When checked, this task creates new tables in the server persistence repository. These tables are destined to support Container Managed Persistence. The structure of the tables corresponds to the beans being deployed. This task pertains to CMP beans only.

Port number of WebSphere node

This port is used for communication between application server and client program. It is assumed that the host is localhost. Before proceeding with the next page of the Deployment Expert, make sure that the server is available for the selected port and host.

Target WebSphere server directory

Specify WebSphere Application Server product installation root.

Launch server in debug mode

If you are going to debug your beans, you can run the server in the debug mode and attach to it from Together's debugger process. Actually, this option does not restart the server in the debug mode, but adds special command line arguments to the application. After that you have to restart the application server from the WebSphere Administrative Console.

Note: A number of additional libraries are required to launch WebSpere in the debug mode. See WebSphere InfoCanter documentation for details.

Debug port number

Enter port number for communucation between WebSphere and external debugger. Server and debugger must use the same port number. (Good advice: keep this number in safe place). You can use the default port number 8787.

Page "Servlet property"

In this page you can enter properties for the Process Servlet(s) and Generate simple JSP client tasks.

Note: In order to access any WEB resource we have to specify URL. Standard Web URL includes protocol, host, port, web resource alias, and path. Path to a resource is implied relative to document root. It consists of directories and file name at the end.

Virtual Host Name

Single WebSphere Application Server can hold and serve several virtual Web hosts. Each virtual host is associated with a set of aliases. By default, only one host is allocated. Its name is default_host. It is associated with the localhost. See Chapter 0.16: What are virtual hosts?, WebShpere InfoCenter documentation for details.

The default_host is used in Together's EJB Deployment Expert by default. If you want to use another virtual host, specify its correct name here.

Servlet Engine Name

Each WebSphere virtual Application Server can hold several Servlet Engines. By default, only one engine is allocated. Its name is Default Servlet Engine. The same name is used in Together's EJB Deployment Expert by default.

If you are going to use another Servlet Engine, specify its name in this field. If the engine with the specified name doesn't exist, it will be created.

Web Application Name

Each WebSphere Servlet Engine can hold several Web Applications. After the server installation there are several web applications. Together's Deployment Expert uses default_app web application.

If you are going to use another web application, specify its name in this field. If the application with the specified name doesn't exist, it will be created.

Web Application Document Root

Each Web application on the WebSphere server has its own Document Root. Document Root is a file system address accessible through an Internet browser. All subdirectories of the root are also accessible. Contents of this field must be equal to the corresponding property of the Web application in the WebSphere Advanced Administrative Console.

Web Application Web Path

Each Web Application on the WebSphere server have its own Web Path. It is a string similar to directory path, which however doesn't refer to any actual directory. This is a Web resource alias for Web application. This Web path is appended to the virtual host alias. For examle, if virtual host is localhost:900 and Web path is /webapp/Examples,then the result will be http//localhost:900/webapp/Examples. If Web Application is empty then, then the Web path consists of a single slash character "/".

Relative Web Path to Servlet(s) directory

In this field you have to specify the part of Web path to access a servlet. This path is a string similar to directory path, which however doesn't refer to any actual directory. It is appended to the Web Application Web Path (see previous paragraph). For examle, if virtual host is localhost:900, Web path is /webapp/Examples and Relative Web Path to Servlet is /servlet, then the result will be http//localhost:900/webapp/Examples/servlet. If Relative Web Path to Servlet is empty then it consists of a single slash character "/".

Servlet Jar File Name

During deployment the servlet is compiled and packed to a JAR file. Servlet archive should be allocated on the classpath of the servlet. This classpath can be assigned at the WebSphere Administrative Console. By default, EJB Deployment Expert puts the servlet archive in the same directory as EJB archive.

Create JSP 1.0 Support Servlet

Check this flag, if you are going to use JSP in your project. This flag indicates whether a special servlet will be added to the Web application. The name of this servlet class is com.sun.jsp.runtime.JspServlet. In WebSphere it is normally called jsp10. This servlet can be added by checking the flag, or manually.

Enable File Serving from this Web Application

Check this flag, if you are going to use HTML resources in your project. This flag indicates whether a special servlet, responsible for processing requests to HTML resources, will be added to the Web application. The name of this servlet class is com.ibm.servlet.engine.webapp.SimpleFileServlet. In WebSphere it is normally called file. This servlet can be added by checking the flag, or manually.

Load Servlets at Startup

This flag indicates whether to load servlet when the application server starts, or wait until the servlet is requested. By default it is set to False.

Enable Servlets

This flag indicates whether the servlet is available to handle requests. By default it is set to True.

Enable Debugging

This flag indicates whether to start the servlet in Java debug mode. By default it is set to False.

Page "Client properties"

This page contains the entries for the properties required to generate start and compile files for teh client task.

Client main class

Enter class name that contains the main method to run the client application. Automatically generated batch files will refer to this class.

Path to the client sources

Enter fully qualified path to the directory where client source files are stored.

Path to the target directory

Enter fully qualified path to the directory where compiled files will be placed.

Page "Simple JSP client generation"

This page shows up if you have checked appropriate flag on the first page of the Expert and contains entries for the properties required to generate a Simple JSP client.

The fields are quite self-explanatory.

Document root directory

Specify the root of file hierarchy, which can be accessed from outside. Thus, if you want to allow access to some HTML of JSP files, you have to place these files under the document root.

Subdirectory for JSP files

To avoid disorder in the public directory it is advisable to group the files in a subdirectory. Enter path to the subdirectory where your files will be stored. This path is relative to the root public directory. If the subdirectory does not exist, it is created automatically (after confirmation).

Root Web path for browsing JSP

In order to browse a remote WEB resource, we have to set its URL. Standard web URL includes protocol, host, port, web resource alias, and path. Specify all parts of the URL, except for the path. During request processing, the server substitutes this base URL to WebSphere public directory in order to access the requested web resource. Wrong value of this field or WebSphere public directory causes access error. By default base URL is http://localhost.

WebSphere JNDI service provider URL

This field is required to establish connection between JSP client and EJB server. Usually, the client must first send request to the name service provider in order to get access to EJB instance. The value entered in this field is inserted into a JSP file in course of generation and is subsequently used during execution. Normally, you do not need to change this field. Default value is iiop://localhost:900.

Show result after generation

Check this box to launch your default Internet browser and display the start page.

Page "Verify/Correct sources"

This page contains entries for Verify/Correct task. The fields are quite self explanatory and allow to terminate deployment if verification fails, correct sources to make them compliant with WAS 3.5, make backup copies and change return types in the created class.

Change return type in the create methods

WebSphere Application Server version 3.5 supports EJB specification 1.0. This is not the latest EJB specification. Later specifications require that create methods of home interface should return primary key type, while the 1.0 specification requires that create method returns void. For the sake of compliance with EJB 1.0 specification, correction program replaces all changes types to void.