Incompatibilities between Sales Center Version 6 and Version 7

IBM Sales Center migration to Version 7 introduces some incompatibilities, which might affect any custom code you have applied to your IBM Sales Center. The following entry describes the areas that changed and provides actions required to resolve the issues. Examine this list if you are experiencing problems running your plug-ins on IBM Sales Center Version 7.

Application attribute definition changes
Product definition attribute changes
API changes because of ICU4J support
Changes in CDATA support
Workbench menus are not loaded properly
Menu definitions now use 'org.eclipse.ui.menus'
Menu bar and status bar implementation changed
InitializeDefaultPreferences deprecated
TableTree is deprecated
Image accessibility implementation changes
Methods removed from the TelesalesImage class
The getActiveEditor method returns null
Accelerator attribute is no longer available in the org.eclipse.ui.view extension point
KEY_CONFIGURATION_ID implementation changed
BUTTON_HEIGHT is not available
The dialog size and location changes
The getId method of IPageDescriptor class returns a simple name
IViewDescriptor changes
The getShowViewActionIds method removed from the WorkbenchPage class
Alternative implementation for the internal Workbench class
Alternative implementation for the internal WorkbenchImages class
Alternative implementation for the internal WorkbenchPlugin class
Alternative implementation for the deprecated BigDecimal class
Alternative implementation for the deprecated EnabledSubmission class
Alternative implementation for the deprecated WorkbenchHelp class
API changes in "RolesRegistry" and "ActivitySetRegistry"
Classes ActivitySetRegistryReader & RoleRegistryReader are removed
Sales Center plugins are not dynamic aware

1. Application attribute definition changes

Description: Sales Center has three application definitions that use the WctApplication and WctWorkbenchApplication classes:

Order Capture Application
Accelerator Web Application
Administration Console Web Application

Action Required: If you have custom application definitions like the ones provided in the IBM Sales Center, change them accordingly. For information about the schema changes to the application extension points, see the following Lotus Expeditor documentation links:

2. Product definition attribute changes

Description: A product definition is defined using the eclipse extension point 'org.eclipse.core.runtime.products'. See http://help.eclipse.org/stable/topic/org.eclipse.platform.doc.isv/reference/extension-points/org_eclipse_core_runtime_products.html.

The application attribute of a product definition denotes the default application to run when running this product. Lotus Expeditor platform provides an application attribute "com.ibm.rcp.personality.framework.RCPApplication" for the applications based on the Lotus Expeditor platform. The Sales Center has its own product definition, and when you upgrade to the new platform the existing product definition has also been updated accordingly.

Action Required: If you have defined your own custom product definitions for your custom product, update them accordingly. See the following topic in the Lotus Expeditor documentation for more information on product configuration.

Product Configuration

3. API changes because of ICU4J support

Description: The following APIs are changed in Version 7 because of the new ICU4J support added.

TicklerRequest#formatGMTDateTime(String gmtDateTime, ULocale locale, int dateStyle, int timeStyle, String pattern)
TicklerRequest#formatToGMTDateTime(String date, ULocale locale, int dateStyle, int timeStyle, String pattern)
Globalization#ULocale getLocale()
Globalization#formatISODate(String isoDate, ULocale locale, int dateStyle, String pattern)
Globalization#formatISODateTime(String isoDateTime, ULocale locale, int dateStyle, int timeStyle, String pattern)
Globalization#formatToISODateTime(String date, ULocale locale, int style, String pattern)
TelesalesUIPlugin#ULocale getLocale()
RefreshTicklersAction#formatToGMTDateTime(String date, ULocale locale, int dateStyle, int timeStyle, String pattern)
DatePicker(Shell parentShell, ULocale locale)
DatePicker(Shell parentShell, ULocale locale, Date start, Date end)
DatePicker#ULocale getLocale()

Action Required: Any customization extending the preceding classes or methods will have issues when you migrate to Version 7. You need to perform updates to use the ULocale class. For more information about how to use ICU4J in your custom plug-ins, see Globalizing your application.

4. Changes in CDATA support

Description: In Sales Center Version 6, the requests you send to the server are encoded. When the requests are encoded, the size of the requests is increased. APAR JR27156 added a toggle to allow for the option of wrapping requests with CDATA in order to avoid the potential performance problem caused by the size of an encoded request.

In Sales Center Version 7, all requests are wrapped with CDATA to avoid the performance problem caused by the size of an encoded request. The Lotus Expeditor platform has in-built support for CDATA. So if you customized your Sales Center Version 6 to enable encoding, you can either remove the customization or disable the CDATA encoding (not recommended) by performing the following steps:

Open the existing config.ini file to work with the System Configurator. See System configurator for more information on the config.ini file.
(Optional) Remove the customization by removing the following entry in the config.ini file:
```
CDATAEncodingEnabled=true
```
(Optional) Disable the CDATA encoding by editing the following entry in the config.ini file.
```
CDATAEncodingEnabled=false
```
Note: Include the preceding code entry in the config.ini file if not already present.
Restart your application.

Action Required: Remove any customization completed for APAR JR27156 (Sales Center 6.0 Fix Pack 4 and above) which introduced "Added an encoding toggle to reduce the size of messages."

5. Workbench menus are not loaded properly

Description: In previous versions, the menu was defined using a separate "actionSets" extension point which might not work in the new platform. The menu has to be moved into the same "actionSets" extension points where action set is defined. For example, suppose your definition for your menu looks like the following code sample in a previous version:

<extension
      point="org.eclipse.ui.actionSets">
      <actionSet
            label="actionset_label"
            id="actionset_id1">
         	<menu
               label="menu_label"
               id="menu_id"
               path="menu_path">
               <groupMarker
                  name="group_marker_name">
               </groupMarker>
         </menu>
	</actionSet>
</extension>

The corresponding action definition would look like this code sample:

<extension
         point="org.eclipse.ui.actionSets">
	<actionSet
     label="actionset_label"
     id="actionset_id2">
     <action
           label=""
           class="action_delegate_id"
           menubarPath="menu_bar_path"
           toolbarPath="tool_bar_path"
           id="action_class_id">
      </action>
 	</actionSet>
 </extension>

Now, you must modify your code to load the menu properly. The modified code would look like the following code sample:

<extension
         point="org.eclipse.ui.actionSets">
<actionSet
      label="actionset_label"
      id="actionset_id2">
		  <menu
          label="menu_label"
          id="menu_id"
          path="menu_path">
          <groupMarker
          	name="group_marker_name">
          </groupMarker>
      </menu>
      <action
          label=""
          class="action_delegate_id"
          menubarPath="menu_bar_path"
          toolbarPath=" tool_bar_path"
          id="action_class_id">
       </action>
   </actionSet>
</extension>

The default menu is also changed as shown. The changes might impact your existing customized code, so you might have to modify your code appropriately. In previous versions, all the menu "IDs" were defined under the

com.ibm.commerce.telesales.ui.actionset.menu.ordersPerspective
actionSet

ID, but have now been moved to individual action sets where the corresponding action definitions are defined.

Action Required: To override your existing menu, you must override your individual action set.

6. Menu definitions now use "org.eclipse.ui.menus"

Description: In Eclipse 3.0, the menu definitions were provided under the "org.eclipse.ui.actionSets" extension point. However, in Eclipse 3.3, the menu definitions are provided under the "org.eclipse.ui.menus" extension point. The new extension point provides better support to control the placement and visibility of menus.

The dynamic menu contributions which were made through the DynamicMenuItems class are no longer supported. The DynamicMenuItems class used the handle of the WorkbenchWindow's menu manager obtained through an eclipse internal class to contribute dynamically to the main menu. Since this is no longer supported, there is no public API to get the handle of the WorkbenchWindow's menu manager. The mechanism to contribute to the main menu dynamically is through the new extension point.

The DynamicMenuItems class has been depreciated and there is no alternative.

Action Required: Consider the menu definition for the store under org.eclipse.ui.actionSets as an example:

		<actionSet
            label="%menuStore"
            id="com.ibm.commerce.telesales.ui.actionset.store">
           <menu
               label="%menuStore"
               id="store"
               path="com.ibm.rcp.ui.viewmenu">
            <groupMarker
                  name="storeStart">
            </groupMarker>
            <groupMarker
                  name="storeEnd">
            </groupMarker>
            <separator
                  name="separator_1">
            </separator>
            <groupMarker
                  name="additions">
            </groupMarker>
            <separator
                  name="separator_2">
            </separator>
            <groupMarker
                  name="properties">
            </groupMarker>
            <separator
                  name="separator_3">
            </separator>
            <groupMarker
                  name="openStoreExt">
            </groupMarker>
        	   </menu>
         	 <action
               label=""
               class="com.ibm.commerce.telesales.ui.impl.actions.CloseStoreWorkbenchActionDelegate"
               menubarPath="store/storeStart"
               id="com.ibm.commerce.telesales.action.CloseStoreAction"
               definitionId="com.ibm.commerce.telesales.ui.closeStoreCommand">
  					 </action>
		</actionSet>

The store menu definition under the new extension point would be as follows:

		<menuContribution
          locationURI="menu:org.eclipse.ui.main.menu">
       <menu
             id="store"
             label="%menuStore">
             
          <separator
                name="storeStart">
          </separator>
          <separator
                name="storeEnd">
          </separator>
          <separator
                name="separator_1"
                visible="true">
          </separator>
          <separator
                name="additions">
          </separator>
          <separator
                name="separator_2">
          </separator>
          <separator
                name="properties">
          </separator>
          <separator
     	           name="properties">
          </separator>
          <separator
                name="separator_3">
          </separator>
          <separator
                name="openStoreExt" 
                visible = "true">
          </separator>
          <dynamic
                class="com.ibm.commerce.telesales.ui.impl.actions.ReopenStoreMenu"
                id="openStoreDynamic">
          </dynamic>
          <visibleWhen
                checkEnabled="false">
             <with
                   variable="activeWorkbenchWindow.activePerspective">
                <equals                      value="com.ibm.commerce.telesales.ordersPerspective">
                </equals>
             </with>
          </visibleWhen>
       </menu> 
		</menuContribution>

The important things to note in the two methods are:

The menu contribution location is controlled. Please refer the documentation for the org.eclipse.ui.menus extension point on the specifying the location of the contribution.
The actions defined in the actionSets extension are not affected. The actionSets can see the menus defined in the new extension and hence the menubar and toolbar paths will be get affected as long as the same id is maintained.
There is no groupMarker in the new extension. A separator itself behaves as a groupMarker. Therefore, groupMarkers can be replaced by separators. The visibility of the separator is controlled through visible attribute which by default is false.
The dynamic contributions made earlier to the custom menus programmatically should now be done through the dynamic as shown in the preceding example.

7. Menu bar and status bar implementation changed

Description: The way in which the menu bar and status bar are constructed for the workbench has changed compared to the previous version. In earlier versions, the menu bar and status bar manager, which loads the menu bar and status bar, was implemented in the perspectiveActivated method. It is now implemented in the partActivated method.

Action Required: N/A

8. InitializeDefaultPreferences deprecated

Description: The IBM Sales Center plug-in preferences were initialized in previous releases with the help of a initializeDefaultPreferences method provided by the AbstractUIPlugin class. The method is deprecated in Eclipse 3.2 and the new implementation initializes the preferences using a "Plugin preference initializer". There was an issue with the approach used in previous releases because the initializeDefaultPreferences method was not being called if the work bench was started using the ";-clean" argument. This issue is fixed in Lotus Expeditor V6.1.1 and later. Once a new initializer class in defined for a plug-in, the initializeDefaultPreferences method implemented in the same plug-in is not invoked. Customized plug-ins that override the initializeDefaultPreferences method of the AbstactUIPlugin class must change the implementation accordingly.

Action Required: You must add an entry in the plugin.xml for the customized plug-in, as shown in the following example:

<extension point="org.eclipse.core.runtime.preferences">
   <initializer class="com.ibm.commerce.telesales.config.preference.PluginPreferenceInitializer"/> 		
</extension>

9. TableTree is deprecated

Description: The TableTree has been deprecated. Most of the support is now provided by the Tree class. The only limitation with the new Tree class is that it no longer supports searching inside the table cells.

Action Required: N/A

10. Image accessibility implementation changes

Description: IBM Sales Center supports different types of buttons and each of these buttons is designed to support accessibility. If a user is using a screen reader utility, when they click a button, it automatically reads out the label of the button specified using the text attribute. Therefore, even for an image button, you must provide a value for the text property to get the accessibility support.

In previous releases the value of the text attribute does not appear on an image button even when the text attribute is specified. However, that behavior is changed as of Eclipse 3.2 and later.

Action Required: The purpose of specifying the text attribute was to support accessibility, and the same support can be provided using the alternate solution:

button.getAccessible().addAccessibleListener(new AccessibleAdapter() {
   public void getName(AccessibleEvent e) {
   if(getText()!=null && getText().equals(""))
      {
         e.result = Resources.getString(getText());
      }
      else
      {
         e.result = Resources.getString(getTooltip());
      }
   }
});

There is no longer a requirement to have the text property specified for Image Buttons.

11. Methods removed from the TelesalesImage class

Description: The getImageDescriptorFromProgram and the getImageCache methods were removed from the TelesalesImages class. Because these public methods were removed, any custom applications directly using these methods is affected.

Action Required: Support is provided based on your specific requirements, if requested.

12. The getActiveEditor method returns null

Description: In Eclipse 3.0, the editor is set to active by default, so the active editor is available before you even start loading the UI elements into the page. In Eclipse 3.2, the editor is not set to active by default. Your custom application might be impacted because of this platform change so you need to re-implement your code using an alternate option.

Action Required: Custom plug-ins must be reimplemented using the alternative option. See the following for more information:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=204908

13. Accelerator attribute is no longer available in the org.eclipse.ui.view extension point

Description: Since Eclipse 3.2, how you define an accelerator key for a view has changed. The accelerator attribute is removed from org.eclipse.ui.views extension point schema, and the getAccelerator method of the IViewDescriptor internal class is removed.

Action Required: If you are using the accelerator attribute to define the accelerator key for a view, you must update your code to follow the new implementation. The new approach defines a new command and key binding for the view to specify the accelerator key. Custom applications must be modified according to the sample code.

Suppose the following code is the sample view definition from previous versions:

<view
   name="Sample View"
   icon="icons/sample_view.gif"
   category="com.test.cat"
   accelerator = "Ctrl+1"
   class="com.test.SampleView"
   id="com.test.SampleView">
</view>

Modify the code accordingly:

Remove the accelerator attribute from the definition, which is highlighted in bold in the following code sample:

<view
   name="Sample View"
   icon="icons/sample_view.gif"
   category="com.test.category.sampleview"
   accelerator = "Ctrl+1"
   class="com.test.SampleView"
   id="com.test.SampleView">
</view>

Define a command associated with the view:

<extension
      point="org.eclipse.ui.commands">
   <command
         name="%command.sampleview.name"
         description="%command.sampleview.description1"
         categoryId="com.test.category.sampleview"
         id="com.test.StoresView">
   </command>
</extension>

Define a command associated with the view

<extension
      point="org.eclipse.ui.bindings">
   <key
         commandId="com.test.StoresView" 
         schemeId="com.ibm.commerce.telesales.ui.telesalesAcceleratorConfiguration"
         sequence="Ctrl+1">
   </key>
</extension>

14. KEY_CONFIGURATION_ID implementation changed

Description: Each action and command that contributes a menu item in the Sales Center workbench is grouped as a "key configuration" using the org.eclipse.ui.commands extension point. Once you define a key configuration, you can set the key configuration active by adding an attribute into the plugin_customization.ini file as shown in the following code sample:

# Setting the default key configuration
org.eclipse.ui/KEY_CONFIGURATION_ID=com.ibm.commerce.telesales.ui.telesalesAcceleratorConfiguration

However, there was an issue in Eclipse 3.0.1 (Sales Center Version 6) where the KEY_CONFIGURATION provided in the plugin_customization.ini file could not be read by the platform. As a result, setting the default key configuration does not set the key configuration as active. Hence, the default key configuration was set in the existing code using the setActiveKeyConfigurationId method of the IMutableCommandManager interface.

In Eclipse 3.2 and later, the IMutableCommandManager interface was removed and the issue with setting the key configuration in the plugin_customization.ini file was fixed. A few code changes using the existing method to define commands, actions, and key configuration can result in a more efficient implementation. The Sales Center fragment.xml file has been modified to introduce these changes.

Action Required: This sample illustrates the changes made to the base code. These changes were made to the Sales Center plug-ins and applied to your custom plug-ins as shown:

Action definition: Starting from Eclipse 3.2, when you define an action, provide an additional attribute definitionId to specify the command name that is associated with the action.

<actionSet label="Sample Action Set" 
              visible="true" 
              id="com.ibm.test.keyconf.actionSet">
      <menu 
            label="Sample &Menu" 
            id="sampleMenu">
         <separator name="sampleGroup"></separator>
      </menu>
      <action 
            icon="icons/sample.gif" 
            id="com.ibm.test.keyconf.actions.SampleAction" 
            label="&Sample Action" 
            menubarPath="sampleMenu/sampleGroup" 
            toolbarPath="sampleGroup" 
            tooltip="Hello, Eclipse world" 
            class="com.ibm.test.keyconf.actions.SampleWorkbenchActionDelegat"            definitionId="com.ibm.test.keyconf.sampleCommand">          
      </action>
</actionSet>

Action delegate: No changes are required for action delegate.

Command, Category definitions, and Key bindings: The code in the following sample illustrates how the command and category definitions were implemented in previous versions:

<extension
      point="org.eclipse.ui.commands">
   <category
         name="Sample Category"
         id="com.ibm.test.keyconf.category.sample"
         description="Sample Category Description">
   </category>
   <command 
         name="Sample Command" 
         description="Sample Command Description" 
         categoryId="com.ibm.test.keyconf.category.sample" 
         id="com.ibm.test.keyconf.sampleCommand">       
   </command>
   <keyBinding
         contextId="com.ibm.test.keyconf.editorScope"
         commandId="com.ibm.test.keyconf.sampleCommand"
         keySequence="Ctr+l CTRL+3"
         keyConfigurationId=‿com.ibm.test.keyconf.keyConfiguration ">
   </keyBinding>
</extension>

Once you move your code to Eclipse 3.2 or later version, the keyBinding definition is not allowed as part of the org.eclipse.ui.commands extension point. This definition must be part of the org.eclipse.ui.bindings extension point separately. The preceding definition would be broken into two as shown:

<extension
			point="org.eclipse.ui.commands"> 	
			<category name="Sample Category"
					description="Sample Category Description"
					id="com.ibm.test.keyconf.category.sample">
			</category>
			<command name="Sample Command"
					description="Sample Command Description"
					categoryId="com.ibm.test.keyconf.category.sample"
					id="com.ibm.test.keyconf.sampleCommand">
			</command>
</extension>

<extension
			point="org.eclipse.ui.bindings">
			<key contextId="com.ibm.test.keyconf.editorScope"
					commandId="com.ibm.test.keyconf.sampleCommand"
					schemeId="com.ibm.test.keyconf.keyConfiguration"
					sequence="CTRL+3">
			</key>
</extension>

Defining key configuration: Each command is grouped under a key configuration to support switching between different key configurations for different operating environments. The key configuration definition is changed between Eclipse 3.0 and Eclipse 3.2 and later versions. The code in the following sample illustrates how the key configuration was implemented in previous versions:

<extension
      point="org.eclipse.ui.commands">
   <activeKeyConfiguration
         keyConfigurationId="com.ibm.test.keyconf.keyConfiguration">
   </activeKeyConfiguration>
   <keyConfiguration
         name="%keyConfiguration.name"
         description="%keyConfiguration.description"             
				 parentId="org.eclipse.ui.defaultAcceleratorConfiguration"                    id="com.ibm.test.keyconf.keyConfiguration">       
	  </keyConfiguration>
</extension>

Since the preceding format is deprecated in Eclipse 3.0 and after, Eclipse 3.2 uses the following alternative to define the key configuration:

<extension
			point="org.eclipse.ui.bindings">
		<scheme
					name="%keyConfiguration.name"
					parentId="org.eclipse.ui.defaultAcceleratorConfiguration"
					description="% keyConfiguration.description" 
					id=" com.ibm.test.keyconf.keyConfiguration">
		</scheme>
</extension>

Setting current active key configuration: Finally, you must define the default key configuration to be activated. In Eclipse 3.0, there was no way to specify the default key configuration in the same configuration file, whereas in Eclipse 3.2 it can be done just by adding an attribute in the plugin_customization.ini file.
In Eclipse 3.0, add the following line to the earlyStartup method of your plug-in:
```
IMutableCommandManager cm = (IMutableCommandManager) 
PlatformUI.getWorkbench().getCommandSupport().getCommandManager();
           
cm.setActiveKeyConfigurationId(System.getProperty("com.ibm.test.keyconf.keyConfiguration", 
"com.ibm.test.keyconf.keyConfiguration"));
```
In Eclipse 3.2 and later, add the following line to plugin_customization.ini file:
```
org.eclipse.ui/KEY_CONFIGURATION_ID=com.ibm.test.keyconf.keyConfiguration
```
Note: Your custom code that uses the old key binding implementation must make the appropriate changes to update the code to the new implementation.

15. BUTTON_HEIGHT is not available

Description: The BUTTON_HEIGHT public attribute from the IDialogContants interface is removed in the current release.

Action Required: Your custom applications that use this attribute must be modified before upgrading to the new release.

16. The dialog size and location changes

Description: After migrating to a new platform, your dialogs might have different location and size.

Action Required: If you find that your dialogs have different location and size after migrating them to the new platform, invoke the pack method of the table object that is a part of the dialog.

17. The getId method of the IPageDescriptor class returns a simple name

Description: If you have code like the following sample, to create a URL provider for the WctWebApplication definition.

public abstract class AutoLogonUrlProvider implements IUrlProvider 
{
...
...
public String constructUrl(IPageDescriptor desc) 
{
String id = desc.getId();

In the new release, the getId method returns a simple name where previously it was returning a DN.

Action Required: Change the custom application to replace the call as illustrated in the following sample, where the change is highlighted in bold:

public abstract class AutoLogonUrlProvider implements IUrlProvider 
{
...
...
public String constructUrl(IPageDescriptor desc) 
{
String id = UIImplPlugin.getUniqueIdentifier()+"."+ desc.getId();

18. IViewDescriptor changes

Description: The org.eclipse.ui.internal.registry.IViewDescriptor class provides a description for a given view so that the view can be later constructed. The view registry provides facilities to map from an extension to an IViewDescriptor. However, this class in removed in the Eclipse 3.2 and later platform. A public alternate is provided in the org.eclipse.ui.views.IViewDescriptor package.

With the class change, the getID method has been modified to getId in the org.eclipse.ui.views.IViewDescriptor public class. The getId method returns the ID of the view.

Action Required: N/A

19. The getShowViewActionIds method removed from the WorkbenchPage class

Description: The getShowViewActionIds method was removed from the Eclipse 3.2 and later. The WorkbenchPage class maintains a collection of views and editors in the workbench. The getShowViewActionIds method gets all the views associated with the current page. This method is used by previous versions of the IBM Sales Center to get all the views associated with the workbench.

Action Required: This same result must be achieved using an alternate public class as illustrated in the following code sample:

20. Alternate implementation for the internal Workbench class

Description: Workbench in the org.eclipse.ui.internal package is an internal class that represents the top of the Eclipse user interface. Its primary responsibility is the management of workbench windows. The Workbench includes dialogs, wizards, and other workbench-related windows. Custom IBM Sales Center applications might be using this class to get the current instance of the editor or of an editor page in the workbench. As it is an internal class, this class must be avoided.

Action Required: Instead of using the Workbench.getInstance method to get the workbench instance, use PlatformUI.getWorkbench.

21. Alternate implementation for the internal WorkbenchImages class

Description: WorkbenchImages in the org.eclipse.ui.internal package is an internal class that provides convenient access to many of the resources required by the workbench. This class stores some images as descriptors and some as real images in the registry.

Action Required: Custom IBM Sales Center applications must be updated to access workbench images without using this internal class as illustrated in the following code sample:

ImageDescriptor desc = 
PlatformUI.getWorkbench().getSharedImages().getImageDescriptor(ISharedImages.IMG_OBJ_FOLDER);

22. Alternate implementation for the internal WorkbenchPlugin class

Description: WorkbenchPlugin in the org.eclipse.ui.internal package is an internal class that represents the top of the workbench user interface. A plug-in class is effectively an application wrapper for a plug-in and its classes. This class is responsible for tracking various registries, including the registries for fonts, preferences, graphics, and the dialog store.

Action Required: Custom IBM Sales Center applications must be updated to ensure that usage of WorkbenchPlugin internal class to get the view registry is modified as shown:

dialog.setData(IDialog.KEY_VIEW_REGISTRY, WorkbenchPlugin.getDefault().getViewRegistry());

Any occurrences of the WorkbenchPlugin.getDefault() must be updated to the new implementation, illustrated in the following code sample:

dialog.setData(IDialog.KEY_VIEW_REGISTRY, PlatformUI.getWorkbench().getViewRegistry());

23. Alternate implementation for the deprecated BigDecimal class

Description: BigDecimal in the com.ibm.math package is deprecated in Eclipse 3.2.

Action Required: Use the BigDecimal class in the java.math package in the IBM JDK 1.5 or later.

24. Alternate implementation for the deprecated EnabledSubmission class

Description: See http://help.eclipse.org/ganymede/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/ui/contexts/EnabledSubmission.html for more information.

Action Required: The alternative way is to use IContextService.activateContext. The following code sample demonstrates the difference between the previous implementation, and the new implementation.

Deprecated implementation: In the editor's init method, consist of the following lines of code:

IWorkbenchContextSupport workbenchContextSupport = 
PlatformUI.getWorkbench().getContextSupport();
enabledSubmission_ = new 
EnabledSubmission(getEditorId(),TelesalesUIPlugin.getShell(), 
getSite(),ITelesalesCommandContextIds.RETURN_EDITOR_SCOPE);
workbenchContextSupport.addEnabledSubmission(enabledSubmission_);

The preceding lines of code help to set the context for each editor that is used by the command.

New implementation: The editor's init method must use the following implementation

Object service = 
PlatformUI.getWorkbench().getService(IContextService.class);
if(service != null)
{
   contextService = (IContextService)service;
   activation = 
         contextService.activateContext(ITelesalesCommandContextIds.RETURN_EDITOR_SCOPE);
}

25. Alternate implementation for the deprecated WorkbenchHelp class

Description: The WorkbenchHelp class provides a way to link editor pages and user assistance topics.

Action Required: The suggested alternate implementation is illustrated in the following code sample:

PlatformUI.getWorkbench().getHelpSystem().setHelp(this, 
System.getProperty(getHelpId(), getHelpId()));

For more information, see the WorkbenchHelp topic in the Eclipse information center.

26. API changes in "RolesRegistry" and "ActivitySetRegistry"

Description: There are four main API changes:

The modified RoleRegistry and ActivitysetRegistry classes no longer extend the internal RegistryManager class, or implement the IRegistryChangeListener interface. The readFromRegistry method now has an alternative implementation. The following code sample represents the class signature from previous versions. The code in bold is removed from the current version:
```
public class RoleRegistry extends RegistryManager implements IRegistryChangeListener{
```
The modified readFromRegistry method of the RoleRegistry and ActivitysetRegistry classes now throws a CoreException. This exception is thrown when there is missing mandatory attribute while defining the "role" or "activitySet" tags using either the com.ibm.commerce.telesales.roles or com.ibm.commerce.telesales.activitySets extension points. See the extension point schema for the extension points for more details.
Any custom code that overrides the readFromRegistry method can be modified to construct a CoreException, and throw that exception to handle any failure that might arise in the code. A CoreException is a subclass of Exception that represents a failure of operation. CoreException contains a status object describing the cause of the problem.
Note: See the Eclipse documentation for more information about CoreException and IStatus classes.
The postChangeProcessing method was removed. If you want to implement the registry change listener, you must write you own code. The actual implementation of the postChangeProcessing method is as a listener method, which is invoked if some thing has changed in the specific extension registry. If there is no relevant change to this registry, the postChangeProcessing method is not invoked.
A new IRegistryEventListener interface is introduced in Eclipse 3.4 and later which listens for registry change events. Changes include the modifications made to the extension points and their extensions.
This interface has methods to check for additions and deletions from the registry. You can implement the postChangeProcessing method to be invoked based on your requirements.
The buildNewCacheObject method was removed. It was removed since it is internally invoked by the RegistryManager class. If you have custom code that is dependant upon the registry listener, you can implement a method after reading the changes to the registry.

Action Required: N/A

27. Classes ActivitySetRegistryReader & RoleRegistryReader are removed

Description: The ActivitysetReader, RoleReader, and PerspectiveStatusLineContributions classes extend the RegistryReader to read the extension registry contents. However, RegistryReader is an internal Eclipse class, and must not be used. An alternative implementation is provided for this part of the base code. The following sample code shows how same thing can be done in a different way:

private void readRoles() throws CoreException
{
   IExtensionRegistry extensionRegistry = Platform.getExtensionRegistry();
   IExtensionPoint point = 
         extensionRegistry.getExtensionPoint(PL_ROLES_EXTENSION);
   if (point != null)
   {
      IExtension[] extensions = point.getExtensions();
      for (int i = 0; i < extensions.length; i++)
      {
         IConfigurationElement elements[] = extensions[i].getConfigurationElements();
         for (int x = 0; x < elements.length; x++)
         {
            IConfigurationElement element = elements[x];
            if (element.getName().equals(TAG_ROLE))
            {
               RoleDescriptor desc = new RoleDescriptor(element);
            this.addRole(desc);
            }
         }
      }
   }
}

The ActivitysetRegistryReader and RoleRegistryReader classes are removed from the new versions of Eclipse. Instead of using the ActivitysetRegistryReader or RoleRegistryReader classes to read extensions, you must modify your custom code to use the preceding approach.

The PerspectiveStatusLineContributions class has been modified appropriately with the new implementation. The ActivitysetRegistryReader or RoleRegistryReader classes are extended by the ActivitySetRegistry and RoleRegistry classes. With the new implementation provided for reading roles and activity sets, the ActivitysetRegistryReader and RoleRegistryReader classes are no longer required.

Another public attribute as shown has changed:

public static final String PL_FEATURE_EXTENSION = 
      "com.ibm.commerce.telesales.ui.statusLineContributions"; //$NON-NLS-1$

This attribute has been changed to add an additional namespace before the attribute. If you use this attribute directly in your code, you must modify the code accordingly.

28. Sales Center plugins are not dynamic aware

Description: Dynamic awareness is introduced to allow plug-ins to handle changes in the contributions to the extension points when plug-ins are dynamically added or removed from the system. Hence, in Eclipse 3.0 and later, the registry objects are meant for short-term use and would get invalidated. As a result, plug-ins dealing with registry objects should be capable of handling object invalidations and changes to the registry objects in order to be called dynamic aware. access.

If a plug-in providing the extension point does not want to be dynamically aware, it can always do so. For this, the plug-in should ensure that no registry objects are cached for use later in the code. This is generally the case when the extension points are lazily used. The contributions are all read once and used only when needed. The reason why the registry objects should not be cached is that, it could become invalid and cause problems when the object is used.

The registry objects are read once during initialization and all the data required from the registry objects is retrieved for later use. Caching all the data instead of the object avoid invalid objects.

Disadvantages of not being dynamic aware are:

The plug-in will not be able handle the dynamic contributions to its extension point.
It will also not be able to deal with cases where contributing plug-ins are uninstalled from the system leaving invalid class references in the contributing plug-in. Hence, the contributing plug-ins should not be uninstalled from the system as long as the plug-in to which the contribution is made is still active and installed on the system.

In Sales Center, the plug-ins are not dynamic aware. Hence, the above points need to be kept in mind to prevent the customizations from crashing.