 | Eric Chaland (echaland@ca.ibm.com)
Advisory Software Developer, IBM
19 November 2003 This article introduces you to the IBM Deployment Toolkit for WebSphere Studio, WebLogic Edition, and shows you how to use it to create, deploy, test, and debug a J2EE application in a BEA WebLogic Server environment. Introduction
This article introduces you to the IBM® Deployment Toolkit for WebSphere® Studio, WebLogic Edition,
(hereafter called the Deployment Toolkit), and shows you how to use it to create, deploy, test, and debug
a J2EE application in a BEA WebLogic Server environment.
The article assumes that you are already familiar with the WebSphere Studio family of products. Overview of the Deployment Toolkit plug-in
The Deployment Toolkit provides tools for working with BEA WebLogic Servers and files in WebSphere Studio.
As of November 2003, the Deployment Toolkit supports WebLogic Server 6.1 and WebLogic Server 7.0.
Support for WebLogic Server 8.1 will be available soon. It is offered as a free download to let you develop, test, and deploy J2EE
applications using the BEA WebLogic Server with WebSphere Studio Site Developer and WebSphere Studio Application Developer.
Your copy of WebLogic Server can be installed on the same machine as WebSphere Studio or on a remote machine,
and you can launch the WebLogic Server console from within WebSphere Studio as an embedded Web application.
The function, integration, and user interface of the Deployment Toolkit is comparable to the equivalent WebSphere Application Server
deploy and test functions in WebSphere Studio V5.0 or later. The Deployment Toolkit is intended for customers who have both WebSphere and WebLogic in their development environments,
either because they're in the process of migrating to WebSphere or simply because they're a heterogeneous shop. The Deployment Toolkit
facilitates migration from WebLogic to WebSphere and makes WebSphere technology available to a wider range of developers.
Download the Deployment Toolkit for WebSphere Studio, WebLogic Edition. Life cycle of an J2EE application
Setting the WebLogic Server preferences
Select Window => Preferences => Server => BEA WebLogic
to open the Preferences page and enter the appropriate values: Figure 1. WebLogic Server preferences
 - BEA home directory
- The directory that contains the BEA license file
- WebLogic 7.0 installation directory
- The directory that contains WebLogic Server 7.0
- WebLogic 7.0 domains directory
- The directory where the WebLogic Server 7.0 domains were created
- WebLogic 6.1 installation directory
- The directory that contains WebLogic Server 6.1
- Java™ home directory
- The directory that contains the Java installation that you wish to use to run the WebLogic server
The WebLogic Server requires the PATH environment variable to be set when the server is started.
The PATH variable must contain the path to a javac executable in order for the server to compile generated EJB and JSP source
code, and it should refer to the Java home location specified in the preferences or explicitly for the server.
This PATH must be set outside of and before starting WebSphere Studio.
The length of the PATH may be limited by the environment size in Windows® operating systems. The PATH will be truncated
if the environment limit is reached, and WebSphere Studio may attempt to start the server with an invalid command line. Creating an EJB project
- Switch to the J2EE perspective.
- Select File => New => EJB Project.
- Select Create 2.0 EJB Project and then select Next.
- Enter an EJB project name. Use the default enterprise application archive (EAR) project name or define one of your own.
- Click Finish to complete the EJB project creation.
- Recommendation: After you create an EJB project, turn off automatic validation to improve performance.
Creating a bean
- Select File => New => Enterprise Bean to create a bean.
- Select Session Bean. Enter the bean name.
- Define
com.ibm.test as a default package. - Click Finish to complete the session bean creation.
- To Create a CMP 2.0 bean, select Entity bean with container-managed persistence (CMP) fields. Select
CMP 2.0 Bean. Enter the bean name and define
com.ibm.test as a default package. - Select the Local client view check box. Select the Remote client view check box if required.
The remote interface defines the business methods that can be called by a client.
- Add persistence fields to the bean. Select Key field if the attribute created is defined as the key field.
Click Finish to complete the CMP bean creation.
Enabling the EJB project for WebLogic Server
- In the J2EE hierarchy view, right-click on the EJB Project and select Enable For WebLogic Server.
- Select Version 7.0 or Version 6.1, depending on your target application server. A folder named
wls70 or wls61 is created containing the deployment descriptors specific to BEA WebLogic Server.
Generating EJB-to-RDB mapping
- In the J2EE hierarchy view, right-click on the EJB Project and then select Generate EJB-to-RDB Mapping.
- Create a new back-end folder or use an existing back-end folder, and then proceed to generate the mapping.
- The Mapping Editor is displayed. Define mappings between your enterprise beans and database elements such as tables and views.
- Switch to the J2EE perspective.
- In the Project Navigator view, expand the EJB project.
- A folder will be available for each version of WebLogic that is enabled for the project. These are labeled
wls70
(for WebLogic Server 7.0) or wls61 (for WebLogic Server 6.1). - Expand the WebLogic folder and double-click on
weblogic-cmp-rdbms-jar.xml to open the file in the XML editor.
For details of how WebLogic CMP and CMR mappings should be configured, see the BEA WebLogic Server documentation. Updating deployment descriptors
- Select the WebLogic 6.1 or 7.0 tab in the Deployment Descriptor editor, depending on your application server target.
- Enter the bean's JNDI name. The JNDI name field is the value you will use for look-ups in the Universal Test Client.
Those values should already be populated.
- Select the CMP bean and enter the data source name
Test in the WebLogic CMP RDBMS field.
Creating database schema and tables
- Run the DDL script against your target database to create the tables and associations to be used with your container-managed bean.
Creating a domain configuration
- Select Programs => BEA WebLogic Platform 7.0 and click on Domain Configuration Wizard.
For information on creating WebLogic 6.1 domains, see the WebLogic documentation.
- Select the template WLS Domain.
- Enter the domain name
testdomain and then click Next. - Select C:\bea\user_projects\ as the domain directory and then click Next.
- Enter the server name
testserver and then click Next. - Enter an Admin user name and a password and proceed to create the domain.
Creating a server and server configuration
- Switch to the Server perspective.
- From the main menu, select File => New => Server and Server Configuration to open the
Create a New Server and Server Configuration wizard.
- In the Server Name field, type
Server. - In the Folder field, select Servers from the drop-down list.
- In the Server type list box, expand BEA WebLogic Server 7.0 (or 6.1)
and select Local Server (or Remote Server Attach if you plan to run on a remote server. Click Next.
- Enter an Admin user name and a password, and then click Next.
- Enter the domain name
testdomain. The server name testserver should appear automatically. - Click Finish to create the server.
Defining a connection pool and data source
- Open the Server editor and select the Classpath tab.
- For DB2 database users, add
C:\Program Files\SQLLIB\Java\db2java.zip to the classpath for the server you are running. - Start the server called Server.
- Once the server is started, click Launch server console from the server editor under the Server tab.
- Enter the Admin user name and password defined previously.
- Under Services Configurations, select Connection Pools to configure a new connection pool, as shown below. In
the example, the database is
DB2 and the database name is SAMPLE.
Figure 2. Connection Pool Definition.
 - Click Create and then select the Targets tab to enable the connection pool
testPool for the target
server testserver. - Select Tx Data Sources to configure a new JDBC TX Data Source.
- The data source name field in the EJB-to-RDB mapping deployment descriptor must match the JNDI name of the data source defined below:
Figure 3. Data source definition.
 - Click Create and then select the Targets tab to enable the TX Data Source
Test for the target
connection pool testPool. - Close the server admin console.
Associating the EAR file with the server configuration
- In the Server Configuration view, expand Server Configuration and then right-click on WebLogic Server Configuration.
- Select Add and click the default EAR file to associate it with the server configuration.
Running and testing an EJB
- In the J2EE hierarchy view, right-click on the EJB Project and select Run on server. This will start the WebLogic
Server and launch the EJB Test Client. There is no need to generate deploy code in the Run on server step for EJB projects since
validation already generated the deploy code.
- Change to the JNDI Explorer page and enter the JNDI name for the session bean and/or CMP bean to perform a lookup.
Figure 4. Universal Test Client -- JNDI Explorer.
 Figure 5. Universal Test Client -- container-managed bean instantiation.
 Best practices
Testing projects remotely
Testing projects on a remote WebLogic Server is similar to testing on a local WebLogic Server, except that you can
only start and stop the WebLogic Server manually, outside of WebSphere Studio.
You can publish and debug a J2EE application running on a remote server by attaching the project to the server.
Before you can test the application on the remote WebLogic Server, the server must be started with the following VM parameters:
-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=7777,server=y,suspend=n Explanation of debug parameters: -Xdebug- Enables debugging
-Xnoagent- Sun's classic VM supports both the old
sun.tools.debug interface and the Java Platform
Debugging Architecture (JPDA); the -Xdebug option enables both, but defaults to running the
sun.tools.debug agent. The -Xnoagent option turns this off so the JPDA will work. -Djava.compiler=NONE- Disables the JIT compiler. Debugging with the classic VM requires that its JIT compiler be disabled.
-Xrunjdwp- Loads in-process debugging libraries and specifies the kind of connection to be made. The
transport=dt_socket option
tells the debugger which transport mechanism to use. Specifying the dt_socket option lets the debugger listen to a socket
for incoming client connections. The other possible value is dt_shmem, which is applicable
when both the debugger and the application server are on the same host. address=7777- The TCP port number you want the debug communication to use.
It should be the same port number that you specified in the remote server configuration.
server=y- Indicates that the JVM is running in debug mode.
suspend=n- Instructs the server not to wait until a debugger connection is established. If the
suspend=y option is used,
then the application server will suspend at the beginning of execution and wait until the debugger attaches to it.
Running the Unit Test Client
The Universal Test Client (UTC) is automatically published to the WebLogic Server if the server has been configured
to enable the UTC by checking the checkbox on the configuration tab of the Server configuration editor. JNDI properties: The initial Factory value should be: weblogic.jndi.WLInitialContextFactory.
The provider URL should be: t3://localhost:7001/. If you want to run the UTC on a remote WebLogic Server,
change the hostname in the Provider URL to the name of the remote host. Importing WebLogic artifacts
Importing a WebLogic-specific EAR file is similar to importing any EAR file. To import a WebLogic-specific EAR file: - Select File => Import.
- Select WebLogic EAR file and then click Next.
- Type or browse to select the name of the WebLogic EAR file that you want to import.
- Type the name of an enterprise application project that will be created when you import the EAR file.
- Click Next. The version of WebLogic that the EAR file requires is automatically selected. You can still set the file
to be enabled to a different WebLogic version.
- Click Next and continue the import process as you would for any other EAR. You can also click Finish at this
point to accept all defaults for importing the EAR file.
- The resulting project will be WebLogic-enabled for the version of WebLogic selected during the import process.
Recommendation: as usual for all WebLogic projects, disable automatic validation.
If the EAR being imported is enabled to a different WebLogic version, the WebLogic-specific EJB
descriptor files for that version will be automatically created for you. Importing a WebLogic-specific WAR file is similar to importing any WAR file. To import a WebLogic-specific WAR file: - Select File => Import.
- Select WebLogic WAR file and then click Next.
- Type or browse to select the name of the WebLogic WAR file that you want to import.
When you import a WebLogic WAR file, the Import Wizard attempts to detect the appropriate WebLogic version by
examining the public ID of the WebLogic-specific Web descriptor (weblogic.xml). The Wizard then invokes the WebSphere
Studio Import WAR mechanism to import the Web module.
After the import is done successfully, the Wizard WebLogic-enables the project. Importing a WebLogic-specific EJB JAR is similar to importing any EJB JAR file. Use the Import wizard, selecting
WebLogic EJB JAR file as the source. When you import a WebLogic EJB JAR, the Import Wizard attempts to detect the appropriate
WebLogic version by examining the public ID of the WebLogic-specific Web descriptor (weblogic-ejb-jar.xml).
The Wizard then invokes the WebSphere Studio Import EJB JAR mechanism to import the EJB module.
After the import is done successfully, the Wizard WebLogic-enables the project. Validating code
Validation of WebLogic-enabled projects is performed in the same manner as it is for other types of projects.
An EJB validator is present for each version of WebLogic that is enabled for the project. The WebLogic validators check the
WebLogic-specific deployment descriptors and also compile the deploy code. Compilation of the deploy code is required to
complete the validation for WebLogic. Because of the performance impact of this compilation, you should disable automatic validation
and perform validation of WebLogic projects manually. A WebSphere Application Server Extensions validator verifies that
the EJBs being validated do not implement WebSphere Application Server extensions that are incompatible with WebLogic Server.
In particular, WebLogic Server does not support: - WebSphere Application Server EJB 1.1 relations
- Bean class inheritance.
- Primitive key fields when the bean participates in a one-to-many relationship
Reusing domains
Users are free to reuse WebLogic domains for server configurations, but proper operation may not be
possible after doing so. Since WebLogic Server is a third-party tool, it is not possible to add WebSphere Studio Workbench-specific
information to WebLogic configuration files. Workbench-specific information is stored in a separate configuration file located in the
workspace, which makes it possible for the two configuration locations to become out of synch if they are modified individually.
If reusing a domain is absolutely necessary, take the following steps to reduce the potential for synchronization problems: - Remove all applications from the configuration using the workbench.
- Uncheck the UTC checkbox.
- Publish the server configuration (this must be completely successful).
After performing these steps, you should be able to delete the server and server configuration and create
new ones that refer to the same WebLogic domain. Doing so enables the serial reuse of a domain, but you cannot implement
parallel (simultaneous) reuse of a domain. New features
JSP debugging
You can debug Java source code in a JSP in the same manner as regular Java code. The Web project must be
enabled for WebLogic. To debug a JSP: - Switch to the J2EE perspective.
- In the Project Navigator view, expand the web project.
- A folder will be available for each version of WebLogic that is enabled for the project. These are labeled
wls70
(for WebLogic Server 7.0) or wls61 (for WebLogic Server 6.1). - Expand the required folder and then double-click on weblogic.xml to open the file in the XML Editor.
- Ensure that the
weblogic.xml file specifies a working directory like this:
<jsp-param>
<param-name>workingDir</param-name>
<param-value>D:\workingDir</param-value>
</jsp-param>
|
where D:\workingDir is a valid path where generated servlet code will be written.
- Also ensure that the JSP parameter keepgenerated is set to true in
weblogic.xml. - Add breakpoints in the JSP. Breakpoints can be set only on lines containing Java source.
- Publish the application to the version of WebLogic that is enabled for the project.
- In the Project Navigator view, right-click on the JSP and select Debug on Server. The WebLogic server will start and
a browser will open to the JSP. Debug execution will stop at the first breakpoint.
Hot deploy
Hot deploy is the ability to publish changed applications to a running server without having to restart the server.
You can do hot deploy by editing an application and then publishing the server configuration. While you can use the BEA hot deploy
for individual EJBs, the Deployment Toolkit uses the enterprise application-level granularity for hot deploy.
It turns out that you won't save much over redeploying the whole application. In fact, most of the time, the server redeploys the
rest of the application as dependencies when you update an EJB using BEA hot deploy. When an application is published to a WebLogic Server, the following things happen: - All deployable projects and their child modules are exported as enterprise application files and stored in a staging directory.
- If the UTC is enabled, the publisher will make a copy of the UTC EAR file, update it with WebLogic-specific information,
and finally store it in the staging directory.
- If the server is already started, the configuration publisher will attempt to deploy all the applications stored in the
staging directory to the active server. Otherwise, deployment happens on the next server start.
Conclusion
The Deployment Toolkit for WebSphere Studio, WebLogic Edition, integrates seamlessly with WebSphere Studio.
It lets you build, deploy, test, and debug J2EE applications on both WebSphere Application Server and BEA WebLogic Server.
Migrating J2EE applications from WebLogic to WebSphere is now much easier because you are freed from the tedious task
of manually updating application server-specific deployment descriptors. You can focus on the business logic of your J2EE
applications while WebSphere Studio takes care of the application server deployment issues. Top of page About the author
Eric Chaland is an Advisory Software Developer who works for the WebSphere Studio ISV Enablement team
at the IBM Toronto Software Lab. He engages with key WebSphere Studio tools partners, providing technical guidance and
support as they integrate into the WebSphere Studio set of products.
|
| |
