Minimum: 512 MB. Recommended: 1 GB for Rational XDE Developer versions

Minimum: 500MB for installation drive, 100 MB for workspace. Recommended: 2-5 GB for workspace

The following operating systems are tested and supported: 

• Windows 2000 Professional, Service Pack 2 or Service Pack 3
• Windows 2000 Server, Service Pack 2 or Service Pack 3
• Windows 2000 Advanced Server, Service Pack 2 or Service Pack 3
• Windows XP Professional, Service Pack 1

Notes:

• This release does not support Windows NT.
• For the latest information about operating system support, check the latest version of this document at http://www.rational.net/XDEcenter.

Level 1 support for these languages:

• Dutch
• Hebrew
• Traditional Chinese
• Korean

Level 2 support for these languages:

• Japanese
• German
• Simplified Chinese
• French
• Italian
• Swedish

Notes:

• XDE cannot be installed into a path that includes Japanese, double-byte, or extended characters.
• The ClearCase 5.0 XDE ClearCase Type Manager installer will not function if VOB directories contain 16-bit characters. Please see Internationalization in "Known Issues."

• Rational XDE Modeler is supported as a stand-alone version that operates in a customized Eclipse shell.
• Rational XDE Developer and Developer Plus are supported in the following development platforms:
  • WebSphere Studio Workbench 2.0.2, which is supplied during installation
  • IBM WebSphere Studio Application Developer 5.0 and 5.0.1
  • IBM WebSphere Studio Application Developer Integration Edition 5.0
  • IBM WebSphere Studio Enterprise Developer 5.0
  • Eclipse 2.0.x

Notes:

• This release does not support Eclipse 2.1.
• This release does not support IBM WebSphere Studio Site Developer or IBM WebSphere Studio Device Developer.
• It is recommended that WebSphere Studio users download the latest WebSphere Studio product patches from IBM. In particular, users of WebSphere Studio Application Developer 5.0.1 should review defect 240508 in "Known Issues" and install the specified update.

• Internet Explorer 5.5 with Service Packs 1 or 2
• Internet Explorer 6 without any service pack or with SP1
• Netscape 7.0

• WebLogic 5.1, 6.1, and 7.0
• WebSphere 4.0 and 5.0
• Sun J2EE Reference Implementation 1.3

Supports:

• Rational ClearCase version 2003.06.00 and ClearCase LT version 2003.06.00.
• Rational ClearCase version 2002.05.00, with the latest required patch level installed.

XDE will display a warning message when the first model is opened if the ClearCase patch level on your system is less than as follows:

• For ClearCase v.2002.05.00, patch 15

To verify the latest patch information for your version of ClearCase, go to http://www.rational.com/support/downloadcenter

To find out which patches your ClearCase installation has installed, use the cleartool -version command in a DOS command prompt window. 

Note:

• Users of IBM WebSphere Studio products who are also using ClearCase LT should see the note in the IBM WebSphere Products section of "Installation Issues," below.

Category

ID

Description

If you attempt to use the Compare With > Each Other menu command when all of the resources selected in the Navigator are XDE artifacts, the shell will appear to hang. The operation may finally complete, provided you have adequate physical/virtual memory, but it may take hours or days to run.

Workaround: Avoid using the Compare With > Each Other command with XDE artifacts. Instead, compare XDE artifacts using the File > Compare/Merge menu command.

Occasionally, you may see that the number of conflicts reported during an XDE Compare/Merge session appears to be inconsistent with the state of the conflict navigation buttons and menu items. For example, the status bar indicator may show that there are two unresolved differences remaining to be resolved when the Navigate to Next Unresolved Difference button and menu item are unavailable. This may happen when conflict resolution propagation automatically resolves other conflicts in response to a conflict you have resolved, as when you resolve a conflict involving the deletion and renaming of a class by deleting the class. In that case, the conflict resolution is automatically propagated to remove views of the deleted class from diagrams, thereby resolving dependent conflicts. However, the conflicts that are resolved automatically may not correctly be reflected by the conflict count.

If you encounter a situation where the status bar count indicates that there are differences remaining to be resolved, yet navigation to the next and previous unresolved differences is not available (dimmed), then the conflict count is incorrect; you have, in fact, resolved all conflicts. In this case, you can ignore any warnings about unresolved conflicts when you save and end your merge session or commit the merge session to ClearCase.

239437

If you initiate a ClearCase operation that leads to an XDE merge session, you may not realize that ClearCase is waiting for the XDE merge session to complete if XDE is minimized or if the ClearCase dialog boxes obscure an XDE dialog box. It may appear that ClearCase is hung.

Workaround: Simply bring XDE to the foreground, if it was minimized, or click the XDE window to bring any of its dialog boxes to the foreground.

If you end a ClearCase-initiated merge session by clicking the Close button, you may see five error messages. To avoid this, please follow the recommended procedure for ending a merge session, which is to use the File > Compare/Merge menu instead of the Close button.

Workaround: Perform several sequential merge sessions in which you fuse two models at time in each session, until you have fused all of the models.

513643

When working with XDE, two users may create storage units with the same name in their versions of the same directory. When the users attempt to check in or deliver their work and a merge is triggered, ClearCase will prompt the user to choose between the two storage units and XDE Compare/Merge will independently ask the user to choose between the two model elements associated with those storage units. In this situation, it is important that you choose consistently. That is, if you choose one user's storage unit, then you should also choose that user's model element associated with that storage unit. For example, suppose both users created class1 as a separate unit in a file named class1.clx in their versions of the same directory. The ClearCase directory merge will ask which of the two class1.clx files should be present in the merged directory and XDE Compare/Merge will ask which of the two class1 model elements to present in the merged model. If the user chooses the first user's class1.clx file during the ClearCase directory merge, then the user should also choose that user's class1 model element during the XDE Compare/Merge session.

Note that if the model element names differ but the storage units are the same, a similar situation arises but the behavior differs. For example, both users might initially create class1 in storage units class1.clx in their versions of the same directory. Then, the first user renames the class1 model element to be myclass. The storage unit retains the name class1.clx. However, in this case XDE Compare/Merge will allow both model elements class1 and myclass into the merge result model even though the ClearCase directory merge will permit only one class1.clx to reside in the directory. The resulting model will be unable to locate the missing storage unit. To recover from this, you should rename the missing class1.clx file to some other name and then locate this renamed file using the Browse to Unit command on the shortcut menu for the model element that is missing its unit. Perform the rename using the ClearCase Explorer or at a cleartool command line so that the history of the renamed file (which includes the file with its original name) is preserved.

The following defect only applies to the Rational XDE Developer - Java Platform Edition: A ClearCase-initiated merge session will fail while comparing or merging two interaction instance units (*.iix), containing at least one lifeline, with each other.

Workaround: Combine the Interaction Instance units with their parent units and start the merge session again. This should be done while no one else is working on these two interaction instance units. If someone else does change these interaction instance units, those other changes will be lost. This occurs because those interaction instance unit files are no longer a part of the model after you combined them into their parent unit files.

When Rational ClearCase initiates an XDE merge session involving a diagram that is a separate unit, occasionally the diagram cannot be opened from the Model Explorer. This occurs when certain information necessary to open the diagram resides in a parent unit of the diagram unit and is, therefore, not present during the merge session.

Workaround: Once the merge session completes, you should be able to open the model and then open the diagram without difficulty.

If you drag and drop a Java class from a Rational ClearCase source-controlled file that has already participated in round-trip engineering operations from one package to another in the Model Explorer and answer "no" when prompted to check out the model, the Java file related to the class will not be placed back into ClearCase version control.

Workaround: You must refresh the package that the file was moved from in the Navigator. You will then be prompted to add the Java file to ClearCase source control. It is possible that you may not be prompted based on ClearCase preference settings. By default, XDE prompts you to add all new files to ClearCase.

When opening a read-only (for example, controlled and checked-in) model created using a previous release of XDE for the first time, and the model is a non-Java Code Model with the Java profile applied, you will see the following error message in the output log:

Error: Exception in MU.doTaggedValues(NME): 
The Operation attempted to modify a read-only element

This error is benign and can be safely ignored. After continuing with the upgrade of the model and saving it, you should not see this error again.

When upgrading older models, the profile upgrade process will not complete successfully if there are any missing model subunit files.

Workaround: A utility that fixes models in this state is available on the Rational Developer Network. If you cannot locate the utility, the Rational XDE v2003 Model Repair Tool, contact Rational Customer Support for assistance.

Users who go off-network will not be presented with the view chooser when using the Rational XDE
in ClearCase view command from the Start menu. Instead, users will be launched into the default workspace for XDE that is used for the non-ClearCase view Start menu command.

Workaround: Use a project set file to load view-resident projects into the default workspace.

Opening a model containing cross-model references in a ClearCase dynamic view may result in the following behavior: Any models that are opened in the process of resolving the cross-model references are not shown as being under source control in the Model Explorer (they do indicate as being source-controlled in the Navigator).

Workaround: Ensure that the client models are opened prior to opening models that contain cross-model references to them. This will allow the client models to be displayed as source-controlled, and therefore they can be modified and checked out from the Model Explorer.

When opening a model from an older version of XDE, the user is prompted to upgrade the model. If the model is version controlled, and it also references another model that is not currently in the shell workspace, an upgrade failure may occur and the model cannot be opened. A Model Upgrade Failed window opens and displays the following message:

Models were not upgraded successfully because some of the files needing change could not be edited.

Workaround: Before upgrading, add the referenced model's project to the shell workspace. If the referencing model is now opened, the upgrade will succeed.

The menu items related to source control may not appear on the shortcut menu for a model in the Model Explorer.

Steps to reproduce the problem:

1. Create a simple project under source control.
2. Add the project to a blank model.
3. When prompted, check in the project.
4. Right-click the model node in the Model Explorer.

To reactivate the menu items, change the focus from model to the main diagram node in the Model Explorer, and then back to the model. This forces the menu items to appear.

Steps to reproduce the problem:

1. User1 creates a basic modeling project in a UCM snapshot view.
2. User1 adds the project and the model to source control.
3. User1 delivers the changes to the default integration stream.
4. User1 creates a new baseline.
5. User2 rebases to the new baseline.
6. User1 makes changes to the model.
7. User1 checks in the model changes.
8. User1 delivers the changes to the default integration stream.
9. User1 creates a new baseline.
10. User2 opens the project and the model in the shell.
11. User2 rebases to the new baseline from the ClearCase menu in the shell.

When steps 2 through 7 occur in less than a minute, the described problem occurs. However, such a scenario is rare and would require unusual speed and coordination.

When a user tries to add newly created and unsaved storage units to source control, the storage units may not be listed in the Add to Source Control dialog box. This issue arises if Do Nothing is selected for the team/Rational ClearCase preference setting When new resources are added.

Workaround: Ensure that the whole model, including newly created storage units, is saved before clicking Add to Source Control.

The transformation feature that creates EJBs from database tables incorrectly creates Container Managed Relationships (CMRs) between CMP 2.0 remote entity beans, which are not permitted.

Workaround: Delete the CMRs and manually create the appropriate source code to invoke the remote beans.

When you use JDBC for DB2 connections, you must verify that the XDE JDBCdriverpath points to the DB2 client. To do this, follow these steps:

1. Before running XDE, click Start > Run, and type regedit.exe.
2. Go to the HKEY_LOCAL_MACHINE\SOFTWARE\Rational Software\XDE\AddIns\Data Modeler registry key, click the JdbcDriverPath value, and then verify that this path is valid and points to your db2java.zip file.

If you have no existing data model, the Class to Table Transformation dialog box does not open when you use the Class to Table command on the Transform menu.

Workaround: Create a data model and use the command again.

Creating new triggers for a table or view will cause an exception if the name of the respective table or view is less than 3 characters in length.

Workaround: When adding a new trigger for a table or view, ensure that the name of the corresponding table or view is at least 3 characters long.

The WebSphere 5.0 deployment descriptors contain the types and names of the columns mapped to CMP fields. There are many different database-specific versions of the deployment descriptors. During deployment from XDE, those types are generated by running an external WebSphere deployment tool and not from the "Data Transform" mapping between EJB and Data Models. Therefore, the values will not reflect your data transformation mappings.

Workaround: If you use WebSphere Studio Application Developer, the best workaround is to use its mapping editor and deployment feature; otherwise, you will have to settle for the default mapping as a first choice. If you must make mapping changes, you have to resort to hand editing the XMI descriptor, which is difficult. However, once you have the correct mapping and schema files generated, XDE can use these files by overriding the normal process that generates new ones. In the deployment model, use the EJBNonModelElements tag on the EJB-Jar Archive to prevent it from being regenerated during deployment.

The online Help for Data Modeling states that you can assign a domain to an attribute in a logical data model. This functionality is not supported.

The following error occurs when an excessively long install pathname is specified:

Error 1320. The specified path is too long <pathname>

If the installation is then cancelled by clicking Cancel, the installer will exit, but the folder %INSTALLDIR%\RCSI\ and its contents will remain on the system. The RCSI folder and its contents should be deleted manually.

If you have installed the Visual Studio .NET edition of XDE, followed by an install of XDE for Java, on the same system, the file associations for the .mdx and other modeling files are now associated with the XDE for Java product. If you uninstall the XDE for Java product, the icons associated with the file associations are uninstalled. This leaves the VS .NET edition of XDE functional, but some file icons are missing and are displayed with Windows generic icons.

Workaround: To restore the icons, reinstall the XDE for VS.NET product.

If you install Rational XDE into WebSphere Studio Application Developer version 5.0, install PurifyPlus (or a Rational Suite product containing PurifyPlus), and you choose to integrate PurifyPlus into Application Developer 5.0, and then uninstall PurifyPlus, you will get a number of harmless error messages the next time you start Application Developer. These errors include, "Error Restoring Editor," "Modeler Error: Failed to load modeler."

Workaround: Exit Application Developer, remove the .metadata directory in your workspace, and restart Application Developer. Application Developer will rebuild a clean metadata directory and the errors will not occur.

Workaround: If you want to use SitePrep.exe directly, it is critical that you configure the shell selection for Rational XDE and Rational PurifyPlus (if installing the Developer Plus Edition) to include only shells known to be present on the target systems that will use the SitePrep area for their install. Do not accept the defaults for the Rational PurifyPlus shell configuration; you must modify the defaults to reflect only shells that are known to be present on the target systems. PurifyPlus shell selection defaults to all supported shells. If you run setup using a SitePrep file that assumes the target machine has all of the shells, and it does not, the problem occurs.

When both the Java Platform and .NET versions of XDE Developer have been installed, model files (.mdx) are associated with whichever version was installed last. If that latter version is then uninstalled, the association is not removed because there is still an XDE Developer version installed. As a result, if an .mdx file is then opened, the wrong association will be used.

Workaround: Manually change the association to the remaining XDE Developer installation shell.

When using XDE integrated with ClearCase, Register New Location fails if the XDE project name contains Japanese or double-byte characters and is under source control.

Workaround: Avoid using Japanese or double-byte characters in project names.

A Rational XDE diagram that contains Japanese or double-byte characters may not display correctly if you copy the diagram and paste it into Microsoft Word. (This is an issue for Japanese and English versions of Word.)

Workaround: Select all shapes, change the font for the selected shapes to an appropriate font, such as MS UI Gothic, and then copy and paste the shapes into Word (or another application).

If the operating system language is different from the language of the character set you are using to enter text, when project files and storage units are created using extended characters, the extended characters are displayed correctly in diagrams, but not in the Model Explorer. Other display character problems may also occur.

Workaround: Ensure that the operating system language and the text-entry language are the same.

Various J2EE server properties, such as EJBResourceRef and WebResourceRef, have a tag editor with a field for a password. While the tag editor obscures the password on the screen by using an echo character, the password itself is still saved in the model as plain text; it is not encrypted.

Workaround: Do not save sensitive passwords in these tags. Use the java.security package to encrypt the password.

Classpath for WebSphere deployment only allows JARs: When deploying to IBM WebSphere Application Server, a classpath is passed to the WebSphere deployment tools. However, these tools only read the JARs in the classpath; they ignore any directories. This means that if you have an EJB project with references to other projects; for example, a Web project, and classes in the referenced project are used by the EJBs, then deployment may fail.

Workaround: Put the compiled objects in the EJB project or create a JAR of the referenced project and add it to the classpath of the EJB project.

When running XDE inside WebSphere Studio Application Developer (or other IDEs in the WebSphere family) on versions of Windows older than Windows XP, J2EE deployment may fail with the following Output messages:

[ J2EE : 2002-12-18 16:08:19 ] [Error Stream] The input line is too long.
[ J2EE : 2002-12-18 16:08:19 ] [Error Stream] The syntax of the command is incorrect.

This indicates that the classpath used during deployment is too long. Deployment uses .bat files provided by the server vendors and a command-line cannot exceed the 255-character limit. This will happen if the classpath is too long.

Workaround: Application Developer adds many unnecessary JARs to the classpath. In the Navigator, select the project and click Properties on the shortcut menu. Click Java Build Path and the Libraries tab. Remove all the WAS_50_PLUGINDIR/... JARs, except for j2ee.jar.

When modeling J2EE applications, use separate projects and code models to model EJB, Web, and client components, including clients used to test one of the other "tiers." (Note that WebSphere Studio Application Developer forces you to use this structure.) By default, when you create deployment models, they automatically get «JARinclude» relationships to the corresponding code models. This step conveniently associates the components to the corresponding JAR. However, if you have servlets and EJBs in the same code model, all of them will get included in the EJB-JAR and WAR that you create. This is a problem when you deploy both tiers to the same machine. Many application servers use the same classpath for both tiers. So, for example, when you invoke a servlet, you may get the servlet located in the EJB-JAR and not the servlet in the WAR. This is especially confusing if the servlet has changed since you last built and deployed the EJB-JAR.

Workaround: Keeping the different tiers in separate models eliminates this potential problem. Alternatively, you can delete the automatically created «JARinclude» relationships and create custom relationships to individual elements. Use the Connector Assistant tool in the Toolbox to create these relationships.

When creating CMP fields in EJBs on an EJB diagram, the abstract CMP get/set methods will appear in the bean class and then quickly disappear. (This is caused by the filtering performed on EJB diagrams.) At this point, if you invoke "undo", the get/set methods will simply reappear. A second "undo" is necessary to actually remove the new CMP field. The same behavior happens when creating similar elements, such as Primary Key Fields.

Workaround: Use "undo" twice to fully remove the newly created items.

When you repeatedly run the Deployment Wizard to set up deployment models, it will not remove items that were added to a deployment model during a previous invocation of the wizard. Clearing those items in the wizard does not remove them from the deployment model.

Workaround: Manually remove the «JARinclude» relationships connecting the obsolete items to the archives (EJB-JAR, WAR, etc.).

Attributes of a class can also be modeled as associations. However, if you transform a class to an Entity EJB, any associations are ignored; they are not mapped to BMP/CMP fields.

Workaround: Convert the association to an attribute before transforming to an EJB.

In some scenarios, the method filtering in EJB diagrams does not work as expected.

• You add a CMP 2.0 field and the corresponding get/set methods are not filtered. Workaround: Delete the class from the diagram (not the model), and then drag and drop it from the Mode Explorer back on the diagram.
• In the diagram preferences (right-click, and then click Customize EJB Diagram), if you clear a type of method (meaning you want it filtered from view), then add a method of that type to the bean. The method is shown in the diagram anyway. Workaround: Open the Preferences dialog box and reset the desired filter settings.
• In the dialog preferences, if you clear all the types of methods that are currently shown in
  one or more beans, meaning that the method compartments in those beans should become empty, instead all the methods are shown in those beans. (Other beans show the expected filtering.) Workaround: Open the shape preferences for each bean filtered in error and click OK.

When you delete an EJB in the IBM WebSphere Studio Application Developer J2EE perspective and save the changes, XDE does not delete it from the EJB Deployment Model if the model is closed, even though XDE opens the model automatically. Errors are reported in the console window.

Workaround: Keep the EJB Deployment Model open when making changes in the J2EE perspective.

The J2EE patterns code templates that are inserted for method bodies are not marked "first-time-only expansion." Hence, every time you synchronize or forward engineer, the code template will be inserted, replacing any code that you added after creating the EJB, servlet, etc. This causes problems for methods that you must change manually.

Workaround: For those methods that you want to modify manually, remove the code template. Select the method in the Model Explorer, right-click, and then click Code Templates > Unbind. In the dialog box, select the Leave Expansion in Code check box if you want to keep the template code that was inserted for that method. Otherwise, it will be deleted. Click Unbind.

Workaround: Make sure cmr-field-name is not the same as ejb-relationship-role-name on the other ejb-relationship-role in the deployment descriptor. This can be corrected immediately after an upgrade from XDE 1.1 by changing the names of the opposite end roles or cmr fields where they are the same value in your XDE model. Also, when you select the relationship, look for the Synchronization property for End1 and End2 of the relationship. Make sure they are both set to Excluded.

Due to a defect in the JSP Compilation Validator in version 5.0.1 of IBM WebSphere Studio Application Developer, you may experience serious problems with various Rational XDE features. If you code-generate a ServerPage in XDE or edit and save a JSP in the editor, certain features will fail, including Add Java > EJB, Add Java > Servlet, and pattern expansions.

Workaround: Download and install the update for Application Developer, "Websphere Studio Application Developer Interim Fix 001." You can use the Update Manager (click Help > Software Updates > Update Manager) or the WebSphere Studio Application Developer downloads site.

When deploying to the Sun J2EE Reference Implementation, the deployment generates the data types for SQL statements from the EJB model, not from any mapped data models. Limited name changes are supported using the EJB mappings to data models since the Sun RI processes the fields in alphabetical order. Also, the tables generated for one-to-many relationships in the Sun RI do not match the XDE transformations.

Workaround: Based on these limitations, users should normally not expect to use the result of the EJB to Data Model feature during deployment to Sun RI.

If you are using XDE integrated with WebSphere Studio Application Developer, you are not permitted to create EJBs in the "root" package, named "ejbModule". However, in some cases, XDE allows you to create EJBs in this package. For example, transforming a database table to an EJB will allow you to select the root package for the new EJBs.

Workaround: Always put EJBs in a subpackage.

Abstract Factory Java needs createConcreteProduct to be create<%=ConcreteProduct%>.

Workaround: Apply the pattern with default values, then rename the participants as needed.

A pattern can have a template parameter of Unified Modeling Language (UML) Type Association and also contain Associations with the same names in the pattern’s Root Context. When the pattern is expanded, the Root Context’s Associations are correctly replaced with the template argument values in the target area, but validation errors are reported.

Workaround: In the Pattern Explorer, set the merge behavior on the template parameter’s Association Type element to Replace. However, a side-effect of the workaround is that the associations are duplicated when the pattern is reapplied.

Facade Pattern: The first operation is not generated when apply multiple operation participants. Workaround: Apply the Facade pattern binding only one operation at a time.

After a user applies a pattern that has a COM Callout or expands a COM Code Template, either in preview mode or in expansion/code generation mode, any modifications to the COM .dll file are not recognized.

Workaround: Modify the file as needed and then shut down or restart Rational XDE.

When a user clicks Cancel in the Apply Pattern Wizard or the Apply Pattern dialog box, a dialog box appears to ask if the user wants to save the binding. Sometimes the binding is saved when No is selected.

Workaround: Perform an undo operation or delete the added binding.

If two developers each add a code template to the same method contained in a configuration-management-controlled model, the code templates can be checked in but not merged. Only one of the code templates can be merged and the other must be re-bound.

Workaround: Do not allow parallel addition of code templates to the same model elements.

For models under configuration-management control, adding more than 16 code templates to the same model may cause the 17th element to appear twice in the element’s bindings when the model is checked-in and merged.

Workaround: Do not bind more than 16 code templates to a CM controlled model element if the model can potentially be merged.

Facade Pattern : Duplicate return type.

Workaround: None

When applying the Iterator Pattern with selected values, errors will occur in the code.

Workaround: Apply the Iterator Pattern with default values, then rename the participants as needed.

The Pattern Explorer's Update Toolbox button does not update the properties for patterns that already appear in the Toolbox.

Workaround: To update an existing Toolbox pattern item, right-click the item in the Toolbox and click Delete. In the Pattern Explorer, click the pattern’s Toolbox node and click the Update Toolbox button in the Pattern Properties window.

Reapply of a pattern does not remove elements added by a previous application of the pattern. For example, a pattern adds an operation with a scripted name, get<%=attributeParamName%>, and the first time the pattern is applied the template argument for the attributeParamName template parameter is Foo and the operation getFoo is added to the model. Then, the user changes the name of the attribute to Bar and reapplies the pattern. A new operation getBar is added, but the old getFoo is not removed.

Workaround: None.

For patterns appearing in the Pattern Explorer and owned by models under configuration-management control, canceling a related checkout may cause the Pattern Explorer to be in an inconsistent state.

Workaround: Close the pattern in the Pattern Explorer and then reopen it.

Most pattern callouts and constraints, when applicable, correctly add error messages to the Output window and an error message box. However, a few messages are instead added to the Task window.

Workaround: None for constraints. For callouts, add messages and specify that they appear in the output window.

Specifying a custom default binding location for all new models in the Preferences or Options dialog box prohibits the creation of any new models.

Workaround: Specify the custom default binding location on a per model basis: Create a new model, and then set the default binding location for that model.

Changes made to patterns properties (such as Expansion Enabled or Expand Nested Bindings) in the Properties window do not always update in the Pattern Properties window.

Workaround: Close and re-open the pattern in the Pattern Explorer.

When upgrading models to this release, the ownership of the first generated or added URL linked to each nested bound collaboration changes. Ownership of the link transfers to the «Asset» package that owns the nested bound collaboration. Other URLs owned by the nested bound collaboration are not changed.

Workaround: Delete any URLs owned by bound collaborations before upgrading the model and manually add them back afterwards.

Bindings of external code templates in models from earlier versions of the product are not being upgraded correctly. After model upgrade, the external code template bindings are still functional in the upgraded model; however, the bindings are no longer suitable for use in situations where the path from the model to the external code template needs to be indirect. Typical situations where this occurs would be when a model is under configuration management and different users view the code template using different paths, or when the code template binding is copied from one model to another via using a pattern application.

Workaround: Find all of the bindings for external code templates in the upgraded model and open the binding for each (using the edit binding command); this will cause the binding to be restored to the proper format.

Some patterns and code template dialog boxes can display intermittent sizing problems, where a subcomponent of the dialog box becomes relatively smaller than the other components.

Workaround: These sizing problems can usually be corrected by resizing the internal components, by dragging the internal sash next to the component. Often, resizing the entire dialog box will also cause the internal components to resize correctly.

View elements created by application of a pattern may duplicate on reapplication of that pattern.

Workaround: In the Pattern Explorer, set the merge hint on the diagram to Replace or Preserve to discard the existing diagram and create a new one or keep the existing one and add a new one (respectively), instead of trying to merge in changes.

Diagrams included in the Root Context may contain elements that are duplicated in the target area diagram as a result of reapplying the pattern.

Workaround: In the Pattern Explorer, set the merge hint on the diagram to Replace or Preserve. The replace behavior discards the existing target diagram and replaces it with the pattern diagram. The preserve behavior adds an additional diagram to the target area.

For generalization, dependencies and realizations, the methods/properties to access the end elements return the opposite end. Specifically:

• IRXEGeneralization.SuperElement returns SubElement
• IRXEGeneralization.SubElement returns SuperElement
• IRXEDependency.SupplierElement returns ClientElement
• IRXEDependency.ClientElement returns SupplierElement
• IRXERealization.SpecificationElement returns ImplementationElement
• IRXERealization.ImplementationElement returns SpecificationElement

Workaround: Use the opposite method/property.

The methods IRXEReference.Resolve() and IRXEReference.getRefModel() always return Null. A call to resolve() will resolve a reference, if possible, but it will still return Null.

Workaround: To get the actual object, use the related method that provided the IRXEReference object -- for example, IRXEGeneralization.getTargetElement() for IRXEGeneralization.getTargetElementReference(). Then, from the actual object, call getModel() to get the referenced model.

The following code is a complete working sample written in Java. You will need to modify the string assigned to modelPath in the main method to point to an existing model on your computer before running this sample.

Finally, in JavaScript, calling the queryInterface method is required to convert an object from one type to another. This is only required when a method returns either an IRXEElement or IRXERelationship object and you wish to access it as a more specific type.

For example, if you wish to access the object returned from getContainer as a class object, and not a generic element, the following code would work:

var thisClass = ctData.getThisElement().getContainer();
var myClass=Interfaces.queryInterface(thisClass, "com.rational.rxe.IRXEClass");

The parameters to queryInterface are the object you wish to convert, and a string containing the full name of the interface you want to convert it to. If the supplied object does not support the target interface, queryInterface returns NULL.

The pattern PostApply callout's lookupParameterValue() method does not work as expected in Visual Basic.

Workaround: None.

RXE elements do not form an inheritance hierarchy of types. For example, an RXE collaboration is not an RXE element. Some RXE documentation may be misleading when referencing these concepts.

Workaround: None.

When called from a patterns OnBind callout, the RXE pattern’s getPatternInstance() method returns null when it should return the pattern instance.

Workaround: None.

The operation getRXE() fails in the Visual Basic PreExpand callout. It may also fail in other Visual Basic RXE callouts.

Workaround: None.

In pattern callouts related to the use of the Apply Pattern Wizard and Apply Pattern dialog box, the
RXE’s getRXE() method does not return the correct value. This method is used to acquire the
RXE application that can be used, for example, to write to the Output window.

Workaround: Obtain an RXE element object by using, for example, the getThisElement() method and then use that element's getApplication() method to obtain the RXE object.

The RXE pattern’s isAborted() method does not return True when the pattern is being aborted.

Workaround: The pattern callout designer can call getNextAction() and use that result to determine the pattern status.

As designed, the OnArgumentValue callout is invoked each time the user selects an argument value in the apply pattern tools. When the OnArgumentValue callout rejects the selected argument value, it is not added as an argument value for the template parameter. However, using OnArgumentValue does not consider the existing set of values to determine whether to add a new element to that set.

Workaround: Eliminate unwanted elements later in the pattern application by adding another callout, such as a PreExpand callout.

134745

When invoked during an OnArgumentValue callout, the lookupParameterValue() operation only retrieves the argument values for the current template parameter. Thus, pattern designers cannot filter out values for a specific parameter by comparing the values assigned to a different parameter.

Workaround: Add another callout to filter elements later in the pattern application process, such as adding a PreExpand callout.

When an OnBind callout or constraint fails, the pattern designer’s failure message text correctly appears in the Output window. However, the designer’s text fails to appear in the error message dialog box that opens when using the Apply Pattern dialog box. No error message appears when using the Apply Pattern Wizard. The Apply button is enabled in the Apply Pattern dialog box even though the OnBind evaluation has failed.

Workaround: None.

Unable to successfully query for the Type value of the CTArgumentValue in a pattern callout so the callout fails.

Workaround: None.

In a pattern callout, the RXE lookupParameterValues() method only returns values that are associated with existing model elements. Because Generated elements have not been created at the PreApply extension point, their values are not available to the callout.

Workaround: None.

When a pattern is applied from a bound collaboration, the OnBind and WizardStartUp callouts cannot use the RXE lookupParameterValues() operation for argument value selection.

Workaround: Pattern designers can use PreExpand or another extension point that is invoked subsequent to the OnBind and WizardStartUp extension points to either abort the pattern or filter elements from the expansion set.

A pattern’s template parameters can have both a collection value source and a user value source. Patterns with both value sources and only user argument values (no collection values are generated), cause a callout’s RXE lookupParameterValues() method to incorrectly return null. Expected return is an array of CTArgumentValueHolders containing the user-entered values.

Workaround: None.

In the Patterns OnBind callout, getThisElement() should return the pattern template because that is the element to which the OnBind callout is attached (the pattern template "owns" the onBind callout). Unfortunately, getThisElement() is returning the model in which the bound collaboration (pattern instance) is located.

Workaround: None.

Unable to successfully specify the name value for a Generated element in a PreApply callout. Without the name value, generated elements cannot be created.

Workaround: None.

The IBM Java Runtime Environment (JRE) that ships with the IBM WebSphere Studio Application Developer platforms does not provide the ability to use Visual Trace when running in debug mode. As a result, users of the Rational XDE Developer Plus for Java Platform Edition who engage Visual Trace will not produce a trace sequence diagram when J2SE applications are run in debug mode.

Workaround: An updated version of the JRE is included with the XDE product media. For installation instructions, see the related "Installation Issues" note under IBM WebSphere Products.

You may see error messages about Visual Trace failing to load when starting Rational XDE Developer Plus for Java Platform Edition after an upgrade from Rational XDE Developer - Java Platform Edition.

If you are performing this upgrade, be sure to accept all pending updates listed in the Configuration Changes dialog box and ignore the two error messages. This will update the workspace and permit Visual Trace to load successfully in XDE.

If you do not accept the listed updates at that point, you can access the update later by clicking Help > Software Updates > Pending Changes. Please contact Customer Support if you need further information.

Workaround: Download and install the hot fix for Rational XDE Developer Plus, "Rational XDE Developer Plus Patch 1," from http://www.rational.com/support/downloadcenter/upgrades/xde.jsp. Note that this fix can also be applied to Rational PurifyPlus for Windows, Rational Purify for Windows, Rational Quantify for Windows, and Rational PureCoverage for Windows.

Visual Trace is not always able to differentiate between applications launched by a user and other processes started as a result of an IDE action. This can result in Visual Trace attempting to trace processes unintentionally and displaying the following warning: "Visual Trace supports only tracing one application at a time. Please stop all other applications being traced and restart the application."

Workaround: For this reason, it is always best to engage trace recording just prior to running your application and to end it immediately afterward.

Visual Trace uses a socket to connect to the application being traced. If a connection cannot be established, the following warning is displayed: "Visual Trace could not establish a socket connection with target."

Workaround: Consider the following options:

• Disable your local firewall.
• Configure your firewall to allow socket connections from the Rational XDE application.
• Configure your local firewall to accept connections on ports between 5001 and 15001.
• Disable other software that may be conflicting with ports between 5001 and 15001.

• The Java Plug-in installation wizard starts and leads you through the installation process. (Internet Explorer)
• You are connected to the Sun Web site to download the Java Plug-in. (Netscape Navigator) 

Workaround: Download the Java Plug-in from the Sun Web site, http://java/sun.com/products,  before you use the publishing/reporting capabilities.

Although the applet is signed by Rational, it could happen that the default security settings for the Java Plug-in version 1.4 do not allow read permission. Workaround: See the instructions under Restrictions and Guidelines on Using this Release, Web Publishing and Reporting.

A model element name that contains an single quote (‘) is truncated at that single quote in the published model tree.

Workaround: Do not use a single quote in a model element name.

You cannot display published models using UNC paths. The Java tree will not load as expected.

Workaround: Map a network drive to the remote machine to view it from a remote system or copy the published model to a local machine to view it locally.

In rare cases, when you publish multiple models successively, you may get the following message, which prevents you from performing any further actions in the model: "A read action is open on behalf of client ‘RSE Client’."

Workaround: Exit and restart Rational XDE.

The Getting Started sample model file may not publish completely when published more than once during the same Rational XDE session.

Workaround: If you want to publish the Getting Started model a second time, close and reopen Rational XDE to create a new session.

If a user name contains an extended character, a path error occurs. This prevents successful publishing and reporting of models and results in the following message: "ParameterFile.txt\ProjectConsole.ini does not exist."

Workaround: In your user directory, there are two folders based on such a user name: one with the extended character presented correctly (for example: Administratör) and one with the extended character presented incorrectly (for example: Administratör). Copy the ProjectConsole.ini file from the incorrectly named folder to the correct folder.

If you are using an installation of Rational XDE that was installed by another user, you may be prompted to install additional components when you attempt to publish a model. The suggested installation is unnecessary; you should click Cancel. Publishing will then proceed normally.

If you allow the process to finish by not clicking Cancel, a second dialog box appears that suggests a restart. You should click No. If you click OK, XDE restarts and the published model is incomplete.

In a published model, displays that rely on a relationship with a MessageEnd object fail. These failures include:

• A sender/receiver table.
• Sequence elements in a sequence diagram that contains a reference between an operation and a message.

If you have installed both Rational Suites and Rational XDE, uninstalling either product will result in failed graphics support for reporting, including diagrams.

Workaround: Reinstalling the product that was removed will resolve this limitation.

If you use Netscape 6.0 as your default browser, and you generate a report or publish a model with the option to "open ... upon completion," Netscape opens behind other windows.

Workaround: Bring the Netscape window to the front by clicking in the status line or by using Alt+Tab. Alternatively, set Internet Explorer as your default browser.

Mnemonic keys (ALT+<key>) do not work in the Preferences window or in the Find/Replace output window.

Workaround: Use Tab and Shift+Tab to navigate to the desired button or field.

Saving models with very long names can lead to problems. The limitations have to do with the Windows limitation of 256 characters for fully qualified path names. To avoid problems,
users should avoid saving models with file names long enough to make the entire path name
longer than 256 characters. Note that, in addition to the saved .mdx file, other support files may be
created that contain additional characters that will add to the overall path length--for example, the .idx file has an additional 31 characters added.

Workaround: Ensure that your path names do not approach the 256-character limitation.

When the zoom factor for a sequence diagram is set to 75% or 50%, you may encounter auto-sizing issues with the box at the top of a lifeline. A long name will appear elided in the box, rather than the box auto-sizing to accommodate the text.

Workaround: Adjust the zoom factor slightly and the box will correctly auto-size.

Rational XDE does not always detect file system changes within the Eclipse project spaces when those changes result from actions performed outside of Eclipse. For example, file changes resulting from the use of an external editor (whether started from within XDE or not) are not automatically detected. However, changes that are made using the internal editors (model changes or changes to Java files using the internal Java editor) will be detected and processed.

Workaround: You can force Eclipse to recognize the changes by right-clicking the project in the Navigator and clicking Refresh.

When copying diagram contents across Windows Terminal Server or Remote Desktop Connection to a local application, such as Microsoft Word, portions of the shapes and connectors are missing in the pasted image.

When you first open models that were created with a prior version of XDE, you are notified an upgrade is required. Once you dismiss the prompt and the upgrade process begins, XDE does not indicate the progress of the upgrade. Depending on your processor speed, available memory, model size, and number of storage units (files), upgrades can take several minutes. Large models can take up to 20 minutes in some cases.

Workaround: Plan in advance for a long, one-time process and wait for it to complete.

Some Rational XDE operations are case-sensitive, which can lead to errors or problems with model dependencies. For example, if you delete a project and then re-create the project using the same name, but not the same case, the dependencies between models are lost.

Workaround: Use consistent capitalization when naming projects to prevent such problems.

When XDE for .NET and XDE for Java are both installed on the same system, attempting to open an XDE model in the Eclipse Navigator with the system editor may cause a "lock" problem.

1. Start XDE and create a model.
2. Close the model.
3. In the Navigator, right-click the model you created and click Open With > System Editor.

The follow error message appears: "Another session is already running in the associated workspace. If this is not the case, please delete the “.lock” file in the workspace “.metadata” directory and try starting the platform again." To proceed, you need to follow the instructions in the message.

The cross-model reference adornment is not displayed in the correct position in the print preview or when you paste the shape into other applications such as text editors.

When you open a saved model that initiates specific internal processes to open a diagram, the model appears in the unsaved or modified state (with an asterisk next to the model name in the Model Explorer), even if you made no modifications to the model. You can safely save or discard the changes without data loss.

Workaround: Save the model again. The next time the model is opened it opens in the saved state.

When you work with subunits, it is recommended that you save your work by using the Save All command on the File menu. If you use the Save command (or Ctrl+S), your work may not be saved consistently.

For example, you may change one subunit, which results in changes in two other subunits. If you save only the first subunit and not the two others, the files saved on disk will be inconsistent with one another. If, instead, you use the File > Save All command, all three changed files will be saved to disk and the files on disk will be consistent with one another.

You can upgrade models created with previous versions of Rational XDE to Rational XDE version 2003. Before you begin the model upgrade process, verify that the read-only attribute is not set on any model files participating in the model upgrade process. For more information, see Rational XDE Help on upgrading models.

Workaround: Rename the model back to its original name. Then, rename all subunit files that have been prefixed with "Copy of" back to the original subunit file names. Note that since the subunit files are hidden in XDE, they must be renamed from the operating system file explorer. The subunit files are in a directory with the same name as the model, in the directory that contains the model.

This defect shows up in two scenarios:

• You are prompted to check out the file if you open a diagram within a source-controlled model and page breaks must be updated due to prior changes in the diagram elements. However, clicking Cancel does not dismiss the dialog box. (This happens if the Prompt for check out setting is selected on the Source Control, General page of the Preferences dialog box.)

  Workaround: Click OK to check out file.

• Rational XDE freezes if you are working with a read-only model and the diagram that you are opening must reset the page breaks due to prior changes in the diagram elements.

  Workaround: Close and restart Rational XDE.

Steps to reproduce:

1. Map to a network drive.
2. Open a Rational XDE model on the network drive.
3. Exit the model without saving it.
4. Disconnect from the network drive.
5. Open XDE and create a new project on a local drive.
   You receive an error informing you that the network drive cannot be found.

Workaround: Reconnect to the previously mapped network drive.

Changes to model subunits will be lost if a model is renamed without being saved first.

Workaround: Ensure that a model is saved before renaming it.

When moving a model with unsaved changes in Navigator from one project to another, the shell detects that the model is changed and reverts the operation. In the process of reverting the operation, the storage units are deleted in the original project, although they remain in the destination project.

Workaround: Avoid this situation by saving all changes before moving a model.

Changing line style of connector from oblique to rectilinear is not always optimal if the oblique line contains only right angles. Changing line style from oblique to rectilinear can reroute the connector, even when the line consists only of right angles. The line routing optimizes for shortest path and will reroute complex right-angled routings when performing the conversion.

Workaround: Manually adjust line routing to suit.

If you open a template model (for example, visualmodel.mdx or GettingStarted.mdx) directly from Windows Explorer, the file is immediately updated as a non-template model. Any models created from a template that was opened in this way will have the same model identifier (GUID), which will cause failures with certain cross-model references.

Workaround: Do not open template models in Windows Explorer. If you have already done so, reinstall the template model from the product CD.

When you create a model and make some of its packages into separate subunits, you must use the Model Explorer to rename or move the subunit files. If you use the Navigator or the file system to do this, the model references to the subunits will be unresolved. Note that the drawing surface will correctly show that the references cannot be resolved, but the Model Explorer will not show the icon that normally indicates unresolved references to model elements.

Category

ID

Description

(800) 433-5444
(toll free)

(408) 863-4000
Cupertino, CA

(781) 676-2460
Lexington, MA

+ 31 (0) 20 4546 200
Netherlands

+31 (0) 20-4546-201
Netherlands

+61-2-9419-0111
Australia

+61-2-9419-0123
Australia