IBM Support

WebSphere Studio Application Developer 5.x and Rational Application Developer version 6.x Best Practices

White Papers


Abstract

This article answers some of the commonly asked questions related to IBM® Rational® Application Developer version 5.x and version 6.x and provides best practice recommendations on a number of different topics.

Content

Table of Contents

Common Best Practices for Rational Application Developer v6

J2EE Best Practices for Rational Application Developer v6

WebSphere Studio Application Developer 5

Change History



Rational Application Developer v6.x

Common Best Practices

Migration:

EJB Migration Scenario (click to expand)
Scenario:

You have migrated your EJB1.x projects to EJB2.1 level using the J2EE migration wizard in Rational Application Developer EJB tooling.


Your CMP beans which were at 1.x level are being shown in the Deployment descriptor to be at 2.x level, but your Actual bean code was written a long time ago and you have the following doubt:


  • The project was created about 2 years ago and Value Object pattern was implemented. Entity Beans now extend from Value Object and inherit properties as well as getters & setters. All of this is moved into the Deployment descriptor with EJB 2.x. Now your Deployment descriptor shows your CMP bean level to be 2.x , though your actual bean code is still at 1.x level.


Note: You should follow the guidelines mentioned in the Rational Application Developer 6.x Information Center if you want to migrate your bean code to the latest 2.x CMP level .
Question 1:

Can you keep your CMP's at level 1.x after you have migrated your EJB1.x projects to EJB2.1 level using the J2EE migration wizard in Rational Application Developer EJB tooling?


Answer:


Yes, it is OK to have level 1.x CMPs with higher level J2EE modules.

Question 2:

Will this impact the rest of the J2EE project modules to have your CMPs at 1.x level inside your (now migrated) EJB 2.x modules?


Answer:


There will be no impact.


J2EE Best Practices


Project Structure:

Deleting <nature> in .project (click to expand)
Scenario:

Your .project file shows the following structure:


      <natures>
            <nature>com.ibm.etools.j2ee.EAR13Nature</nature>


<nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature>
            <nature>com.ibm.wtp.j2ee.EARNature</nature>
      </natures>


You want to know if the first nature, <nature>com.ibm.etools.j2ee.EAR13Nature</nature>, can be safely removed.


Your J2EE 1.3 project has since migrated to 1.4. You are wondering if the EAR13Nature is present because there the WTP's EARNature is present.


Question:


Can a specific <nature> be deleted from the .project?


Answer:


For backward compatibility you need old nature, if you do not need to open the projects in the prior version of Rational Application Developer once you have migrated, you could remove them.


Note: There is a menu option on the EAR project, Remove Compatibility for this purpose.



The following <nature> lines appear in the Rational Application Developer .project file:


  • Rational Application Developer 5.x
    <nature>com.ibm.etools.j2ee.EAR13Nature</nature>

  • Rational Application Developer 6.x
    <nature>com.ibm.wtp.j2ee.EARNature</nature>

  • Rational Application Developer 7.x
    <nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature>
Disable export of enhanced configuration files (click to expand)
Question:

Is there any way to disable the export of WebSphere Application Server enhanced configuration files (such as security.xml) when exporting an EAR project to an EAR file?


Answer:


The only way to do this is to delete the files.

Renaming the Enterprise Application (click to expand)
Scenario:

You would like to create an Enterprise Application project that has a Web Dynamic Project and a Java Project and distribute it to your developers so that they can use the project as a template project and do not need a project from scratch.


When importing the template Enterprise Application project, you want to change the name from Template to a proper name for the project.


Note: It is not possible to re-name Enterprise Application project name by right clicking the Enterprise Application project in Project Explorer > [Refactor] > [Rename].



Question:


Can you change the Enterprise Application name?


Answer:


The Refactor > Rename action is a Java action contributed from base Eclipse™.  Unfortunately this action is not extensible, so IBM Rational can not add extended hooks to handle the refactoring of J2EE metadata when this action is executed.  Since Enterprise Application projects are not Java projects, this action is not present when right clicking on Enterprise Applications.  Though it may seem trivial, the refactoring of Enterprise Applications can get rather tricky when dealing with may sub projects.  Furthermore, only refactoring Enterprise Applications (and not modules as well) would be an incomplete refactor story.  Thus, no J2EE refactoring support was added in Rational Application Developer 6.x (or WebSphere Studio Application Developer 5.x), and none is planned in the 6.x streams.


WORKAROUND:


The best solution is to develop your template Enterprise Application and Web Modules (and other modules) and export it as an EAR.  Then, whoever needs to use the template EAR to create a new Enterprise Application should use EAR import to import it into their workspace.  During the Import, they can change the name of the EAR project and all the module projects, utility projects and web library projects.

Migrating 1.x CMP with J2EE wizard (click to expand)
Scenario:

When you have a 2.1 EJB project defined that contains 1.x CMP bean inside it, you CAN NOT run the J2EE migration wizard against it. If you are using a 2.0 EJB project containing the same 1.x CMP bean, then you can use the J2EE Migration wizard to migrate it up 2.x CMP bean level but can not in a 2.1 project.



Question:


If you have a 1.1 CMP bean inside of a 2.1 EJB project, how can you migrate that bean to a higher level?


Answer:


There is no way to open the J2EE migration wizard on a 1.4 J2EE level project even if there are back level beans that could be migrated.


WORKAROUND:


The following steps worked with a simple test case to manually backport the EJB Deployment descriptor back to 2.0:


  1. Open the ejb-jar.xml with a text editor and comment out this line:

    <ejb-jar id="ejb-jar_ID" version="2.1" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">

  2. Add the following 2 lines in its place:

    <!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
Export EAR project to EAR file (click to expand)
Question:

How do you export an EAR project to an EAR file without exporting WebSphere Application Server enhanced configuration files?


Answer:


The only way to do this is to delete the WebSphere Application Server enhanced configuration files.

Creating EJB Project wide resource references (click to expand)
Question:

Is it possible to create EJB Project wide resource references in EJB in the deployment description on the references tab?


Answer:


The J2EE spec does not allow resource references (or any other reference) at the global level for EJB modules while it is allowed for the web modules.


WebSphere Studio Application Developer v5

Server Targeting (click to expand)
Question:

How do you enable server targeting in WebSphere Studio Application Developer?


Answer:


The following article provides an in-depth explanation of Server Targeting in WSAD 5.1.1:

http://www.ibm.com/developerworks/websphere/library/techarticles/0402_berg/0402_berg.html



Change History (click to expand)
Change History
05 November 2008Initial Release




[{"Product":{"code":"SSRTLW","label":"Rational Application Developer for WebSphere Software"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Documentation","Platform":[{"code":"PF033","label":"Windows"},{"code":"PF016","label":"Linux"}],"Version":"6.0;6.0.0.1;6.0.1;6.0.1.1;6.0.1.2","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
17 June 2018

UID

swg27013752