IBM Support

Rational Application Developer version 7.0.x.x Best Practices

White Papers


Abstract

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

Content

Table of Contents

Common Best Practices

J2EE Best Practices

Miscellaneous

Change History



Common Best Practices

Migration:

Tacit Migrations Opening Workspace (click to expand)
Scenario:

When opening an existing workspace, a tacit migration operation is processing and will not allow other activities to proceed.  This operation usually gets stuck at 5% for hours and can only be cleared by several restarts of the workbench. 


Question:


What can be done to avoid this very time consuming operation?


Answer:


Ensure the time stamp on the .compatibility file matches the first line in the .compatibility file.


Details:


The tacit migration job always runs when the workbench is started.  The actual migration should only run once per project. Every subsequent tacit migration should just be a very short job which simply checks to see whether it should run, should see that it doesn't need to, and then exits.  The check that is made is on the .compatibility file which is at the root of every project. 


If the .compatibility file time stamp does not match the time stamp on the first line of the file, then the full migration is run.


If the two time stamps match, then nothing happens.

Adding .settings folder to source control (click to expand)
Scenario:

This is a general question about WebSphere Studio Application Developer v5.1.2 to Rational Application Developer v7 migration using Rational ClearCase®.


You are debating if you should check-in the .settings folder as this would mean that any time a developer wants to target a different server or use the 5.0 compiler, they would have to hijack these files since they will be under source control.


Question:


Does Rational have any recommendations about storing the .settings folder outside of the project?


Answer:


The .settings folder must be stored in Rational ClearCase (or CVS is that is the version control system being used).

J2EE migration side-effects (click to expand)
Scenario:

You have tried the J2EE Migration Wizard and changed just the WebSphere Application Server version to 6.1. After the migration, the WebSphere Application Server Extended EJB 6.1 facet is activated so that the Lightweight EJB feature is available.


Question:


What are the J2EE migration wizard side-effects if the J2EE specification level is not changed but the server version is changed?


Answer:


There may be possible side effects of using the J2EE Migration Wizard when only changing the runtime.


Note: This feature has been removed as of version 7.0.0.2.


WORKAROUND:


Changing the facets is another  way to accomplish the task of changing the runtime.


  1. Select in project properties of the enterprise project the target runtimes tab

  2. Select Project facets in project properties of EJB project, select add/remove facets.

  3. Deactivate facet WebSphere EJB (Extended) 6.0 and WebSphere 6.0 Click finish

  4. Click add/remove project facets

    Result: WebSphere EJB (Extended) 6.1 appears automatically

  5. Select WebSphere EJB (Extended) 6.1, Click finish, Click OK

    Result: WebSphere Application Server 6.1 and build path still okay. Lightweight EJB option appears.
Disable the migration builder (click to expand)
Question 1:

Can the com.ibm.etools.common.migration.MigrationBuilder migration builder be disabled once the projects have been successfully migrated to Rational Application Developer v7? 


Question 2:


Does this impact any functionality within Rational Application Developer if this is removed?               


Answer:


The migration builder is used to keep Rational Application Developer version 6 and version 7 meta-data in sync.  This is so projects can be be used by both Rational Application Developer 6 and 7 at the same time.  The Migration builder is designed to run whenever changes are made to the workspace and ensure those changes are properly persisted in Rational Application Developer 6 or 5.1.2 meta-data format.  If you do not require the projects to be usable in Rational Application Developer 6 or 5, then it is possible to disable this migration feature.


There are preference settings under Window > Preferences > Backwards Compatibility for which earlier version of Rational Application Developer projects should be backwards compatible.  If you do not need the projects to be backwards compatible, (for example those projects will never be used again by and earlier version of Rational Application Developer), then it is OK to disable all Backwards Compatibility.  After having disabled Backwards Compatibility, you should go through the projects in the workspace and right click on each of them and choose Remove Compatibility from the context menu popup.  This will remove the Migration Builder along with other related meta-data.  Once Backwards Compatibility is removed from a project, this project will no longer work in earlier versions of Rational Application Developer (Applicable from Rational Application Developer version 7.0.0.3 and later).

Web project seen as Java project (click to expand)
Scenario:

You have migrated a Web project from Rational Application Developer v6 using CVS into Rational Application Developer v7,


Question:


Why is the Web project (from Rational Application Developer v6) now recognized as Java project after being migrated into Rational Application Developer v7?


Answer:


The problem here is not a Rational Application Developer problem, rather it is a CVS problem. 


Your project interchange has a .cvsignore file at the root of your CVS project. This file is used by the CVS server to ignore files and directories specified in this file.  This .cvsignore file contains ignore flags for all the vital workspace meta-data including the .project, and .j2ee files.  These files are what Rational Application Developer uses to determine the type of project. 


You need to either remove the .cvsignore file from your project or delete all the entries within it.

Verify proper workspace migration (click to expand)
Question:

Is there a migration tool that can help me verify that my workspace migrated properly from Rational Application Developer version 6 to version 7?


Answer:


Yes. Please find more information about the migration validation tool at:

http://www-01.ibm.com/support/docview.wss?uid=swg21318011



After the migration, use the migration validation tool to check your workspace for consistency. In case of an error, copy the output in the Migration Results view into a Rich text or Microsoft Word document to keep the color coding. Engage support with this document and describe your problem.

Disclaimer

All source code and/or binaries attached to this document are referred to here as "the Program". IBM is not providing program services of any kind for the Program. IBM is providing the Program on an "AS IS" basis without warranty of any kind. IBM WILL NOT BE LIABLE FOR ANY ACTUAL, DIRECT, SPECIAL, INCIDENTAL, OR INDIRECT DAMAGES OR FOR ANY ECONOMIC CONSEQUENTIAL DAMAGES (INCLUDING LOST PROFITS OR SAVINGS), EVEN IF IBM, OR ITS RESELLER, HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Back to top



J2EE Best Practices


EJB Tooling:

Global reference name of data source (click to expand)
Question:

How do you set up the reference name for the data source at the global level in the EJB project?


Answer:


It is not possible to set the resource reference at the project level. This is due to how the EJB specification was designed.

Promote method in superclass to interface (click to expand)
Question:

How do you promote methods in superclass to interfaces?


Answer:


There is no way the Enterprise Bean > Promote to XXXInterfacet action can promote methods in superclasses to interfaces.


WORKAROUND:


The best workaround is to open the desired interface using the Java editor.  Then type Control-Space to invoke code assist.  There will be an option to override each method defined in any super interface.  If there are many methods, and if the desired method name is known, then you could also type the first few characters of the method name  before typing Control-Space to refine the list.


Deployment Descriptor Editors:

Editing parameters (click to expand)
Question:

The Web DD editor allows you to add parameters but does not allow you to edit them or see their values.


Note: It has been observed that in WebSphere Studio Application Developer, you can double click on the parameter and it will bring up a window that allows for editing while in Rational Application Developer v7 you can only do this from the source.


How can you edit parameters in Rational Application Developer?


Answer:


The editing of parameters has been moved to the Properties view in Rational Application Developer 7.


Project Structure:

Source code control and the .compatibility file (click to expand)
Question:

Should the ".compatibility" file be added to source code control?


Answer:


The .compatibility file should be checked into the source code control repository. 


Setting CVS (for example) to ignore the .compatibility file should work (in theory) though you may incur some performance hits as backward & forward migration works by checking the time stamps of the .compatibility file and comparing them with the time stamps of the meta-data files.


Note: IBM Rational has not tested this scenario, so be cautious and test thoroughly in your environment before proceeding.


For example, if a you make some changes in 5.x and check them into CVS (the .compatibility file is a v6 artifact so it will not be changed).  Next, when the first user in v6 synchs up with the repository, the migration builder will see that the v5 meta-data changed and that it is newer than the .compatibility file; therefore, the migration must continue and update any affect v6 meta-data.  If the .compatibility file is then checked in by the first v6 user, when the second v6 user synchs up, no migration will be deemed necessary (because the time stamp of the .compatibility file is up to date). 


However, if the .compatibility file is CVS ignored, then it will not be checked in by the first user, so when the second user synchs up migration will run again (though it should not need to actually update anything).  The performance hit should not be too bad however, and will only occur during a CVS synch, and only when project meta-data changes. 

Removing the .compatibility file (click to expand)
Scenario:

In Rational Application Developer v7.0.0.6, you have a build script that checks out projects from CVS.  You note that even if "backwards compatibility" is disable, a .compatibility file is created.  Your build script has a problem with this because the contents of the project are no longer the same as what is in CVS.   You also note that the .project file is modified as well which is another file that does not match what is in CVS. These changes are preventing the automation of your build.


Question:


What is the proper way to remove the .compatibility file and what is the proper way to disable compatibility mode in a project?


Answer:


The proper way to remove the .compatibility file is to run the remove compatibility action on the project (applicable for Rational Application Developer 7.0.0.3 or later).  You can do this by right clicking on the project and then selecting J2EE > remove compatibility.  These projects will then no longer be backwards compatible and the .compatibility file will no longer be created. 


To prevent new projects from being backwards compatible, ensure backwards compatibility is disabled in the Preferences. The disable preference only applies when new projects are created in version 7.0.0.6 and later.

Accidentally deleting the classpath container (click to expand)
Scenario:

You inadvertently deleted the classpath container entry for the WebSphere v6 Test Environment in your Application Client Project.


The underlying XML in the classpath file is

<classpathentry kind="con" path="com.ibm.wtp.server.java.core.container/


com.ibm.ws.ast.st.runtime.core.runtimeTarget.v60/was.base.v6"/>


You could not find a way of adding the entry back through the GUI; however, you were able to add the entry directly into the .classpath file and it reappeared in the GUI.


You are concerned about editing the .classpath directly.


Question:


How do you edit the .classpath file through the Rational Application Developer GUI?


Answer:


The .classpath file is available for edit from the Java Build Path > Libraries > Add Library menu.

Build path contains duplicate entry (click to expand)
Scenario:

The error "Build path contains duplicate entry" occurs when changing J2EE module dependencies and then requires the projects be configured in a specific order.


You cannot remove the J2EE module dependencies because they are needed at runtime in WebSphere Application Server.


Question:


What happens when dependencies are added using the J2EE Module dependencies properties page to cause this error?


Answer:


When you add the dependencies using the J2EE Module dependencies properties page, several things happen.


The file META-INF/MANIFEST.MF will contain a Class-Path entry for the project you selected on the J2EE Module dependencies, e.g. XYZ.jar if you selected project XYZ.


This modification triggers the EAR Libraries classpath container to update and add the project as a classpath dependency. 

When you return into the Java Build Path page and attempt to add the binary project from the Projects tab, JDT will attempt to add another entry, only it is already there through the EAR Libraries classpath container; hence the error.

Project References property (click to expand)
Question:

The essential purpose of "Project References" property of Java related Projects (Java, EJB, Dynamic Web, EAR) is unclear. By setting "Project References", we can resolve the references to classes that are in the other projects; however, for building the application, to set Java Build Path > Projects property is enough to resolve the references to the classes in the other projects. For executing an application, "Project References" is not relevant to resolve the runtime class references.


What is the exact objective or meaning of "Project Preference" project property? Is it just an alternative of Java Build Path > Projects project property?


Answer:


Project references with respect the J2EE and Java projects are a hold over from earlier versions of Rational Application Developer.  Previously, they were used to compute the build order of projects, for example if there were a reference from project A to project B, in order for the build to work properly project B needs to be built before project A.  Rational Application Developer 7 does not use project references to compute build order and they are not needed.


Similarly, Java build path references can be used to setup the classpath between projects.  The problem is that this is a workspace level artifact and will not be used at runtime.  When the J2EE application is deployed to WebSphere Application Server, these Java build path references have no meaning and thus you will run into runtime errors when resolving classes.  WebSphere Application Server uses the META-INF/MANIFEST.MF Class-Path property to resolve application level dependencies (per the J2EE specification).


The correct way to setup inter-module dependencies in Rational Application Developer is to use the J2EE Module Dependencies properties page.  This will ensure that the META-INF/MANIFEST Class-Path property is properly set for the runtime.  This will also automatically setup the correct workspace classpath dependencies via the EAR Libraries Classpath container.  This is the only setting that needs to be set.  These dependencies can also be setup by directly editing the META-INF/MANIFEST.MF file.

About mixed client versions (click to expand)
Scenario:

While using Rational Application Developer 7 you notice that when you add a Java project to an .ear to be used as a utility project, Rational Application Developer alters .project, .classpath and adds the folder .settings/. This might be a problem because others within your organization will be using this project in Rational Application Developer version 6 or even WebSphere Studio Application Developer 5.1.


Question:

Will compatibility mode ensure that the changes do not break users who are using the project in a previous version?


Answer:


Yes, compatibility mode will ensure that the changes do not break users who are using the project in a previous version.


The changes in the .project, and .settings folder are necessary for the utility projects to be properly linked to the EAR in v7, so you must check these change in.


The changes in the .classpath file, introduce new classpath containers to Rational Application Developer v7 which are not present in v6 or WebSphere Studio Application Developer. 


  • The org.eclipse.jst.j2ee.internal.module.container
    corresponds to the EAR Libraries classpath container in v7.

  • The org.eclipse.jst.server.core.container/
    com.ibm.ws.ast.st.runtime.runtimeTarget.v61/
    was.base.v61     is the server runtime libraries in v7. 

    Neither of these containers will work on earlier versions. 


WORKAROUNDS:

There are two workarounds to the classpath containers problem. 


  1. Remove the containers from v7. 

    Note: The downside of removing the containers is you will have to manage the classpaths yourself, though since these projects are already setup, it should not be an issue.  These classpath containers offer convenience over previous versions of Rational Application Developer in grouping related entries and also reducing the numbers of files needed to be changed when you change the structure of your J2EE applications.  However, they are not needed because you can add all entries using the Java Build path page.  Keep in mind that Rational Application Developer relies on these classpath containers to keep the build path up to date, so certain actions, like updating the META-INF/MANIFEST.MF classpath will require an additional action on your part to update the Java Build path with the corresponding classpath entry if you remove these containers.
    Also, since Rational Application Developer 7.0.0.4, you can disable before migration the usage of J2EE Classpath containers. This can be done via the J2EE preference page . It is recommended to use a newer version of Rational Application Developer such as version 7.0.0.7 in connection with these options.

  2. Configure the project compiler settings in the older workspaces to ignore build path errors. 

    Note: The issue here is that if the project is relying on those classpath containers in Rational Application Developer v7, then you will be missing entries on Rational Application Developer v6 and WebSphere Studio Application Developer. This is why removing the containers is preferred.

Back to top



Miscellaneous

Start Tomcat v5.0 server (click to expand)
Question:

How does J2EE Server Tooling start a Tomcat v5.0 server through Rational Application Developer v7.0.0.5 and later?


Answer:


Tomcat Server is Base Eclipse functionality starting in 7.0.0.5.

War Import Wizard Settings (click to expand)
Question:

Rational Application Developer version 6 War Import Wizard has the setting of "Overwriting existing resources without warning" but version 7 War Import Wizard does not have this setting; however, version 7 Help states that you can select the "Overwriting existing resources without warning" setting as stated below:


"Note that if you select an existing project, you must decide whether you want to select the setting to overwrite existing resources without warning"


In Rational Application Developer 7, what is the correct way of importing a War file into an existing Web project that overwrites the existing resources?


Answer:


IBM Rational no longer supports importing a WAR into an existing project. 


WORKAROUND:


As the WAR is basically a zip file, you can unzip the archive onto the file system, and then refresh your projects.


Note: Be aware of the folder structure in the WAR and the actual web project. You should unzip to a temp directory first. For example, you have a web project that contains index.jsp in WebContent; however, in the .war file the path indicates the files would extract directly under the unzip directory (meaning the path for this file is blank). Depending on your folder structure in the web project this may require careful checking.

Export EAR does not export classes in JAR (click to expand)

Question:

You have created a Java project with a binary jar and have added a dependency on this project from your ear project. When you export the EAR, the classes in the jar are not exported into the jar in the ear. Is this a bug?


Answer:


In Rational Application Developer version 6, a module dependency was added when an entry was made to the .classpath file of a project. Consequently, during import, a project was needed to be created with the binary jar in it (in the same workspace as the project that the customer was working on).


This practice is no longer needed in Rational Application Developer 7, as the usage of binary modules has been simplified, following these steps:


  1. Instead of adding the binary jars to a separate project, copy them into the EAR project (at the root). For example Rad7BinaryTestJava.jar

  2. Delete the Rad7BinaryTestJava project from the workspace.

  3. Export as ear.


Now you will see that the Rad7BinaryTestJava.jar has been exported correctly, with all the class files in it.

For more information, review the following developerWorks article written by Jason Sholl and Gary Karasiuk: http://www.ibm.com/developerworks/rational/library/07/0619_karasiuk_sholl/


Back to top


Change History (click to expand)



Change History
05 November 208Initial 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":"7.0;7.0.0.1;7.0.0.2;7.0.0.3;7.0.0.4;7.0.0.5;7.0.0.6;7.0.0.7;7.0.0.8","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
17 June 2018

UID

swg27013754

Page Feedback