Step By Step Migration From ADF 10g to 11g

1.    Introduction

For the JDeveloper 11g production release, our goal is to support migration of JDeveloper/ADF 10.1.3 applications to the 11g release with minimal-to-no manual changes. In this JDeveloper 11g release, while migration is mostly automated, a few known migration issues with ADF Faces-based 10.1.3 applications are listed in the release notes. To assist you in better understanding these issues, this paper walks step-by-step through the migration of the ADFBC version of the familiar 10.1.3 SRDemo sample application. We hope that this information will make it easier for you to try migrating your own 10.1.3 ADF Faces applications to help us find additional migration problems that need fixing by before our JDeveloper 11g production release.

2.  Overview of Automated Migration Support

JDeveloper 11g supports automated migration of workspaces from 10.1.2.x and 10.1.3.x releases. This section describes the supported migration paths and provides more specific migration details about the automated migration of 10.1.3 JSF applications which use ADF Faces components like the SRDemo sample does.

2.1 Supported Migration Paths

After making a backup copy of your existing JDeveloper 10.1.2.x or 10.1.3.x workspace, you can open the workspace in JDeveloper 11.1.1.0.0 release. All necessary files will undergo migration at this time, in some cases after acknowledging some choices in a Migration Wizard. In general, you should take the default choices for migrating your application. If direct migration of a JDeveloper 10.1.2 workspace fails for any reason, try again to first migrate the 10.1.2 workspace to 10.1.3.3, then to migrate the 10.1.3.3 workspace to 11g to see if the migration is more successful.

2.2 Changes Made to All ADF Applications During the Migration

For all ADF applications, the automated migration performs the following changes:

·     Creates a new .adf/META-INF directory containing adf-config.xml, connections.xml, and credential-jazn-data.xml configuration files.

·     Creates an offline database named DATABASE1 to hold any offline database schema from the 10.1.3 project.

·     Updates Oracle ADF metadata files are updated appropriately

·     Changes import statements referencing JDK 1.8-style Collections API to use the compatible java.util Collections API

2.3 Additional Changes Made to Web Applications

In addition, if the application you migrate is a web application, the migration performs the following additional changes:

·     Updates web application descriptors and libraries to the Web (a.k.a. Servlet) specification version 2.5

·     Adds a WebLogic-application.xml deployment descriptor

·     Upgrades use of JSTL 1.0 tags and libraries to JSTL 1.2

·     Upgrades use of JSF 1.1 tags and libraries to JSF 1.2

2.4 Further Changes Made to JSF Applications Using ADF Faces 10.1.3 Components

If the web application you migrate uses JavaServer Faces with the Oracle ADF Faces component library, then you will want to migrate it to use the Apache Trinidad components in 11g. This ensures you will continue to have visual WYSIWYG design time support for page design, since JDeveloper 11g does not provide for WYSIWYG support for working with 10.1.3 ADF Faces component library. The Apache Trinidad components are an open source JSF component library based on Oracle's donation of ADF Faces 10.1.3 components. Understandably, the Apache Trinidad components are therefore very similar to the ADF Faces components on which they were based. However, they are a distinct component library with a distinct identifying namespace and in some cases different names for the UI components.

JDeveloper 11g automatically updates your 10.1.3 ADF Faces application pages to use the corresponding Apache Trinidad components during automatic migration. Specifically, the migration performs the following additional changes:

·     Updates usages of Oracle ADF Faces 10.1.3 tags and libraries to corresponding Apache Trinidad equivalents

·     Updates Oracle ADF Faces 10.1.3 web.xml configuration information to appropriate versions to work with Apache Trinidad

·     Updates import statements in custom Java code referencing ADF Faces 10.1.3 API's to the corresponding classes from the Apache Trinidad library.

3.   Performing the Automated Migration on the SRDemo Sample

To gain experience in migrating an ADF 10.1.3 web application using JSF and ADF Faces, we'll use the familiar SRDemo Sample application (ADF BC Version). Perform the following steps to carry out the migration:

·     Download and Install the Studio Editon of JDeveloper 11g

Please download the Studio Edition of JDeveloper 11g from the JDeveloper product center on OTN to follow along with the remaining steps.

NOTE:

This migration tutorial was tested with JDeveloper 11g Studio Edition Version 11.1.1.0.0 Build JDEVADF_MAIN.BOXER_GENERIC_081002.2127.5156

·     Ensure You Have Installed the JUnit Extension Before Migrating

The SRDemo sample (ADFBC Version) uses JUnit for unit testing. You need to ensure that you have installed the JUnit extension before performing the migration. To do this, use the Help | Check for Updates... and install the appropriate JUnit extension for the JDeveloper 11g release. The extension will be named JUnit Integration 11.1.1.0.XX.YY.ZZ .

·     Download and Extract the Original 10.1.3 SRDemo Sample (ADFBC Version)

To ensure you can follow these instructions exactly, we recommend that you download the original 10.1.3 SRDemo Sample (ADFBC Version) to use as the starting point for migration. Once downloaded, unzip the SRDemoSampleADFBC.zip file to a convenient directory using jar, unzip, WinZip or another zip file utility. It will create a top-level SRDemoSampleADFBC directory containing all of the files in the demo.

·     Startup JDeveloper 11g and Open the SRDemoSampleADFBC Workspace

Startup JDeveloper 11g and choose File | Open... . Select the SRDemoSampleADFBC.jws file in the SRDemoSampleADFBC directory you extracted above.

The Migration Wizard will automatically appear.

·     Migrate the Application Using the Migration Wizard Dialog

To start the migration process, in the Migration Wizard dialog, do the following:

1.    On the Welcome page, click (Next)

2.    On the Confirmation page, take the default choice of Yes to the Do you want to migrate these files? radio group, then click (Next)

3.    On the Webapp 2.5 Migration page, leave the Migrate to Webapp 2.5 checkbox checked, then click (Next) .

4.    On the Component IDs page, leave the Migrate Component IDs and the Randomize IDs in included pages checkboxes checked, then press (Next)

5.    On the Trinidad Migration page, leave the Migrate to Trinidad checkbox checked, and click (Next) .

6.    On the Finish page, click (Finish)

The actual migration may take several minutes. The Migration Progress dialog gives you feedback about what is occurring.

·     Finish Migration and Save All the Migrated Files

At last, when the final Migration Progress dialog appears summarizing the projects that were migrated, click (OK) .

Then, choose File | Save All to save all of the migrated workspace files.

4.  Manual Changes Required to ADF BC Configurations Using Datasources After Migration

If any of your application module configurations use a JDBC datasource, as the SRDemo sample's SRServiceLocal configuration does, then you need to update those configurations to ensure that the jbo.server.internal_connection is set to the name of an existing datasource. In JDeveloper 11g, when you create an application resources connection named SRDemo, by default the IDE will automatically generate a WebLogic JDBC module for that connection whenever you run or debug the application on the integrated WebLogic application server. As part of that JDBC module's settings, it will configure its JNDI name to be jdbc/SRDemoDS. In addition, JDeveloper 11g will add an entry into the application's web.xml file to reference the datasource as an application resource. The bottom line is that your application can lookup the datasource using the JNDI name under the application resources JNDI namespace. Specifically, the correct JNDI name to use for the jdbc/SRDemoDS datasource will be java:comp/env/jdbc/SRDemoDS. This is the same string that the SRServiceLocal configuration is already using for its datasource, so we can leave that as it is. The one property in this configuration that needs to be changed is the jbo.server.internal_connection property, since it refers to a JNDI name java:comp/env/jdbc/SRDemoCoreDS (with the additional Core in the name) which no longer exists.

So, to perform this update do the following:

·     Right-click on the SRService application module in the DataModel project in the Application Navigator and choose Configurations...

·     When the Manage Configurations dialog appears, select the SRServiceLocal configuration in the list at the left of the dialog, and click (Edit...)

·     When the Edit Business Components Configuration dialog appears, select the Properties tab (the third one).

·     Scroll to find the jbo.server.internal_connection property and update its value to read java:comp/env/jdbc/SRDemoDS

·     Click (OK) , then click (OK) again to dismiss the Manage Configurations dialog.

5.  Manual Changes Required to ADF Faces Code After Migration

Start by rebuilding the application to identify the few places we'll need to change ADF Faces API code. In this preview release, these require manual resolution. To rebuild the application, do the following:

1.    Choose Build | Clean All from the main menu.

2.    Acknowledge the Cleaning SRDemoSampleADFBC.jws dialog

3.    Choose Build | Make All from the main menu.

You should encounter four compilation errors in the UserInterface project due to small changes in the Apache Trinidad core components APIs as compared with those supported by the ADF Faces 10.1.3 core components:

·     In the oracle.srdemo.view.backing.SRMain class:

Error(87,23): method setTip(null) not found
in class org.apache.myfaces.trinidad.component.core.input.CoreSelectBooleanCheckbox
Error(137,36): method getSelectionState() not found
in class org.apache.myfaces.trinidad.component.core.data.CoreTable

·     In the oracle.srdemo.view.menu.MenuItem class:

Error(19,38): identifier CoreCommandMenuItem not found

·     In the oracle.srdemo.view.menu.TrainModelAdapter class:

Error(23,24): constructor ProcessMenuModel(Object, String, Object) not found
in class org.apache.myfaces.trinidad.model.ProcessMenuModel

Perform the following changes to resolve these compilation errors:

·     Fix Compilation Errors in SRMain.java

On line 87 of SRMain.java, change:

getConfidential().setTip(null);

to this:

getConfidential().setShortDesc(null);

TIP:

To quickly go to a class with a reported compilation error, double-click on the error in the log window. To enable line numbers in the source code editor, right-click in the left margin area and choose Toggle Line Numbers . To go to a specific line number, choose Navigate | Go to line... or press Ctrl G.

On line 137, change:

Set keySet = getHistoryTable().getSelectionState().getKeySet();

to this:

Set keySet = getHistoryTable().getSelectedRowKeys();

·     Fix Compilation Errors in MenuItem.java

On line 19 of MenuItem.java, change:

private String _type = CoreCommandMenuItem.TYPE_DEFAULT;

to:

private String _type = "default";

·     Fix Compilation Errors in TrainModelAdapter.java

On line 25 of TrainModelAdapter.java, change:

getMaxPathKey());

to:

(String)getMaxPathKey());

·     Rebuild the Application

Finally, rebuild the application to ensure all of the compilation errors have been resolved. To do this, perform these steps:

1.    Click on the workspace dropdown list in the Application Navigator to ensure the SRDemoSampleADFBC workspace is the current workspace.

2.    Choose Build | Clean All ,

3.    Acknowledge the Cleaning SRDemoSampleADFBC.jws dialog

4.    Choose Build | Make All from the main menu.

The application should now be free of any compilation errors. You can ignore the several deprecation warnings.

6.  Adding Helper Code to Map Trinidad Table Keys to ADF Row Keys

The SRDemo sample's SRMain.jspx page contains a UI table of service history rows. This table is configured to allow multiple-selection. The (Delete Service History Record) button on this page is configured to invoke an ADF method action binding named deleteServiceHistoryNotes. This action binding invokes the method of the same name on the SRService application module, passing in a java.util.Set of oracle.jbo.Key objects as a parameter. The deleteServiceHistoryNotes action binding's rowKey parameter contains the EL expression ${backing_SRMain.historyTable.selectionState.keySet} which passes the set of currently selected keys in the table.

In 10.1.3, the ADF Faces CoreTable class' selectionState.keySet property returns a Set of selected row keys. In Apache Trinidad, the corresponding CoreTable class' selectedRowKeys property also returns a Set of row keys. However, under the covers the two differ in implementation in that the ADF Faces implementation returns a Set or oracle.jbo.Key objects, while the Trinidad implementation returns a Set of String keys.

The SRDemo sample — arguably incorrectly — takes advantage of the implementation detail that the ADF Faces CoreTable returned a Set of oracle.jbo.Key objects to pass this directly to the application module method. So, upon migrating to Trinidad, we need to add a helper method to map the Set of CoreTable row keys into a Set of oracle.jbo.Key objects. To do so, find the OnPageLoadBackingBeanBase class in the UserInterface project and add the indicated helper code below. This helper code will allow us to reference a Map-valued property named selectedAdfRowKeys which will return a Set<Key> when passed an instance of a CoreTable as a map key. In a later step of this document, we'll make a corresponding change to the page definition of the SRMain.jspx page to adjust to this new syntax.

TIP:

To quickly go to a class by name, choose Navigate | Go to Java Class... or press Ctrl+ Minus, then begin to type the name of the class to subset the list and choose the one you want. (No need to remember what package it is in!) The classpath of the currently active project — as determined by its library list and project dependencies — provides the context for the set of class names that you can find using this mechanism. If you are unable to find the class you're looking for, then select the project in the Application Navigator to set the right context for the search and then try again.

Add the lines of code between the two comments below into the OnPageLoadBackingBeanBase class as shown here:

public class OnPageLoadBackingBeanBase implements PagePhaseListener {
private BindingContainer bc = null;
// ----------- ADD THE LINES BELOW ----------
private Map<CoreTable,Set<Key>> selectedAdfRowKeys = new HashMap(){
public Object get(Object key) {
if (key instanceof CoreTable) {
return getSelectedAdfRowKeys((CoreTable)key);
}
throw new RuntimeException("selectedAdfRowKeys[] key not a Core Table!");
}
};
public Map<CoreTable,Set<Key>> getSelectedAdfRowKeys() {
return selectedAdfRowKeys;
}
public Set<Key> getSelectedAdfRowKeys(CoreTable table) {
Set<Key> retVal = new HashSet<Key>();
for (Object opaqueFacesRowKey : table.getSelectedRowKeys()) {
table.setRowKey(opaqueFacesRowKey);
JUCtrlValueBindingRef rowData = (JUCtrlValueBindingRef)table.getRowData();
retVal.add(rowData.getRow().getKey());
}
return retVal;
}
// ----------- ADD THE LINES ABOVE ----------
/*
* ... etc. ... Rest of existing class here
*/
}

To compile this newly-added code, you'll also need to add the following additional import statements to the top of the file (in the same section as the existing import statements). By default the import section will appear collapsed in the code editor. Click the plus sign in the margin at the left to expand it.

import java.util.HashMap;
import java.util.HashSet;
import java.util.Map;
import java.util.Set;
import oracle.jbo.Key;
import oracle.jbo.uicli.binding.JUCtrlValueBindingRef;
import org.apache.myfaces.trinidad.component.core.data.CoreTable;

7.  Manual Changes Required to JSF Pages After Migration

In this release, a small number of manual changes are required to your JSF pages after migration due to known issues. Perform the following steps:

·     Add Whitespace After Colon in EL Expressions Using Ternary Operation to Avoid JSF 1.2 EL Runtime Error

The JSF 1.2 Expression Language (EL) evaluator currently throws an ELException at runtime trying to parse the : (colon) symbol in ternary expressions if it is immediately followed by an alphabetic character. The easiest way to workaround this issue is to search for such occurrences in your pages and add whitespace around the : in the ternary expression. The SRDemo encounters this problem in only one of its pages. [Bug 6408848]

Open the ./app/staff/SRSearch.jspx page and select the Source tab at the bottom of the editor. Line 94 contains the consecutive characters :row as shown here.

<tr:outputText
value="#{row.AssignedDate eq null?res['srsearch.highlightUnassigned']:row.AssignedDate}"
...

The colon needs to be separated from the identifier row by whitespace to avoid the error. So change the EL expression to have whitespace after the : like this:

<tr:outputText
value="#{row.AssignedDate eq null?res['srsearch.highlightUnassigned']: row.AssignedDate}"
...

TIP:	To quickly navigate to any file by name, choose Navigate | Go to File... or press Ctrl+ Alt+ Minus, then begin to type the name of the file to subset the list and choose the one you want. (No need to remember what directory it is in!)

·     Add Immediate="true" To Buttons Bound to Delete Actions If Not Present

As a best practice, a JSF command component like a "Cancel" or "Rollback" button should have its immediate property set to true to avoid posting any user data in the current form before carrying out the operation. The SRDemo's SRMain.jspx page inadvertently did not correctly follow this best practice for the (Cancel) button in the "Add Note" panel in the page.

Due to an ADF Faces 10.1.3 issue [Bug 5918302] now fixed in 11g, this best-practice setting of the immediate property went unnoticed. Here's why. In JDeveloper 10.1.3 with ADF Faces, when client-side mandatory attribute enforcement is not in use, a form submitted with empty values for server-side mandatory fields is not correctly validated if the user has not changed the data of any field in the form. Due to this incorrect ADF Faces behavior, the 10.1.3 SRDemo's (Cancel) button worked as expected since no validation was triggered in this case. In 11g, the validation is correctly triggered now so we need to correct the situation by adding the immediate="true" property to this (Cancel) button.

To carry out this correction, do the following:

1.    Open the SRMain.jspx and select the Source tab to see the page source

2.    Search for the <tr:panelBox> tag with id="addNotesPanel"

3.    Inside this panel, find the <tr:commandButton> for the cancel operation. It will look like this:

<tr:commandButton text="#{res['srdemo.cancel']}"
action="#{backing_SRMain.onCancelAddNote}"/>

4.    Add the immediate="true" attribute so that it looks like this:

<tr:commandButton text="#{res['srdemo.cancel']}"
action="#{backing_SRMain.onCancelAddNote}"
immediate="true" />

8.  Manual Changes Required to Page Definitions After Migration

Perform the following changes:

·     Adjust Reference to Table SelectionState

The ADF Faces table has a property named selectionState whose nested property keySet returns a Set of keys for the selected rows. The Apache Trinidad table has a property named selectedRowKeys that similarly returns a Set of keys for the selected rows. In an earlier step of this document, we added in some helper code into the OnPageLoadBackingBeanBase class to allow declaratively mapping the Set of Trinidad table keys to a corresponding Set of oracle.jbo.Key objects. We need to change the reference to selectionState.keySet in the SRMain.jspx page's page definition to use the this helper code.

To perform this, do the following:

·                         Right-click page ./app/SRMain.jspx in the Application Navigator and choose Go to Page Definition .

·                         Expand the deleteServiceHistoryNotes action binding node in bindings section of the Structure Window

·                         Select the keySet parameter child node inside the deleteServiceHistoryNotes action binding

·                         In the Property Inspector, change the the NDValue property value expression from ${backing_SRMain.historyTable.selectionState.keySet} to ${backing_SRMain.selectedAdfRowKeys[backing_SRMain.historyTable]}

9.  Replace adfFacesContext References with Trinidad requestContext

In this release, the migration wizard automates substituting references to adfFacesContext by the Trinidad equivalent requestContext in pages and page definitions, however if you have referenced adfFacesContext in Java code, you need to make this subsitution manually. So we need to use JDeveloper's search/replace in files functionality to accomplish this manually. Perform these steps:

·     Select the UserInterface project in the Application Navigator

·     Select Search | Replace in Files... from the main menu.

The Replace in Files dialog appears.

·     Enter adfFacesContext in the Search Text field

·     Enter requestContext in the Replace With field

·     Ensure the Options are set as follows:

·                         [ x ] Match Case

·                         [ x ] Recurse into Directory

·                         [ ] Match Whole Word Only

·                         [ ] Preview Change

·     Then click (OK) .

10.   Installing the SRDEMO Schema If Necessary

The SRDemo schema is defined in a series of SQL scripts stored in the SRDemoSampleADFBC/DatabaseSchema/scripts directory. If you need to create the SRDEMO schema and the demo tables, then open a command shell window and do the following:

1.    Change directory to ./SRDemoSampleADFBC/DatabaseSchema/scripts

2.    If you need to install against a remote database...

·     If you are on Windows...

set LOCAL= tnsname_of_remote_db

·     If you are on Unix...

setenv TWO_TASK tnsname_of_remote_db

3.    As user SYSTEM, run the build.sql script:

sqlplus system/manager @build.sql

4.    As user SRDEMO, run the createContextPackage.sql script and the createContextPackageBody.sql script.

sqlplus srdemo/ORACLE @createContextPackage.sql
Package created.
SQL> @createContextPackageBody.sql
Package body created.
SQL> exit

NOTE:

If you are using the Oracle 11g database, passwords are now case-sensitive by default so you need to enter the srdemo user's password as ORACLE as shown in uppercase since that is how the build.sql script creates it.

11.  Adjust the Application Connection Properties If Necessary

The application migration will automatically create an application resource database connection for the ADF Business Components project, based on the information found in the *.jpx and *.xcfg configuration files being migrated. For the SRDemo migration in particular, an application resources connection named SRDemo is created. If you are not running the demo against a local Oracle database whose SID is named ORCL and whose TNS listener process is listening on the default port of 1521, then you'll need to adjust the properties of this connection to point to where you have created the SRDEMO schema you want to use.

To do this, expand the Application Resources zone of the Application Navigator, expand the Connection folder and its contained Database node to select Properties... on the right-mouse menu of the SRDemo connection. Review the connection settings and change them if necessary to point to the SRDEMO account you want to run against. Use the (Test Connection) button to ensure that you can successfully connect, then press (OK)

12.  Migrate the Security

For any application using JAAS security like the SRDemo Sample, when you migrate to 11g you must migrate its security settings. Most of the work is automated by running a wizard. Perform these steps:

·     Run the ADF Security Wizard

Select the UserInterface project in the Application Navigator and then choose Application | Secure > Configure ADF Security... from the main menu.

1.    On the Enable ADF Security page of the wizard, in the Security Model radio group, select the ADF Authentication item, then press (Next>)

2.    On the Select authentication type page, notice that Form-Based Authentication is automatically selected and that the infrastructure/SRLogin.jspx page is inferred for both the Login Page and the Error Page .

Add a leading slash in front of both of the file names so that they read:

·                         Login Page: /infrastructure/SRLogin.jspx

·                         Error Page: /infrastructure/SRLogin.jspx

3.    On the Select authenticated welcome page page, click (Next)

4.    On the Summary page, click (Finish)

Finally, acknowledge the Security Infrastructure Created dialog by clicking (OK) .

·     Remove ConfigurationData from Three Project's Source Path

Three projects in the SRDemo shared security information from a separate directory named ConfigurationData. After performing the security migration above, this is no longer needed so must be removed. Perform the following steps:

·                         Remove the ConfigurationData directory from UserInterface Project

Double-click the UserInterface project in the Application Navigator. On the Project Source Paths page of the Project Properties dialog, in the Java Source Paths: list box, select the entry with ConfigurationData in the name and click (Remove) , then click (OK) .

·                         Remove the ConfigurationData directory from UnitTests Project

Double-click the UnitTests project in the Application Navigator. On the Project Source Paths page of the Project Properties dialog, in the Java Source Paths: list box, select the entry with ConfigurationData in the name and click (Remove) , then click (OK) .

·                         Remove the ConfigurationData directory from DataModel Project

Double-click the DataModel project in the Application Navigator. On the Project Source Paths page of the Project Properties dialog, in the Java Source Paths: list box, select the entry with ConfigurationData in the name and click (Remove) , then click (OK) .

·     Copy Previous jazn-data.xml Entries to New Location

To migrate the jazn-data.xml entries being used by the SRDemo in the ConfigurationData directory to the new jazn-data.xml file created by the Configure ADF Security wizard above, do the following:

0.    Open the New jazn-data.xml File in JDeveloper

Expand the Application Resources accordion panel of the Application Navigator and expand the Descriptors > META-INF folders. Double-click on the jazn-data.xml file you find there. Select the Source tab to view the source of this file.

1.    Remove the jazn-realm element and all its contents

Select the text beginning with the <jazn-realm> element and ending with (and including) the matching </jazn-realm> element, and delete the text.

2.    Copy Previous jazn-data.xml Entries to the Clipboard

Using a text editor like Notepad, open the ./SRDemoSampleADFBC/ConfigurationData/src/META-INF/jazn-data.xml file in a text editor, and copy all of the lines in the file beginning with the <jazn-realm> element and ending with (and including) the matching </jazn-realm> element, and copy them to the clipboard.

3.    Paste Clipboard into New jazn-data.xml File

Back in JDeveloper, in the new jazn-data.xml file, position your cursor between the <jazn-data> opening tag and </jazn-data> tags, before the <policy-store> tag, and paste the contents of the clipboard into the file. Then save all your changes.

·     Delete the ConfigurationData Directory

After exiting the editor you opened above to copy the previous jazn-data.xml contents, at this point, you can remove the ConfigurationData directory to make it more clear that the security information is no longer coming from the files in that directory.

·     Ensure Each User's Credentials Are At Least 8 Characters Long

Oracle WebLogic server requires that the credential (i.e. password) of each user in the jazn-data.xml file be at least 8 characters long. The password for each user in the SRDemo's jazn-data.xml file was welcome, which is only seven characters long, so we need to change each users password to welcome1 to avoid a deployment exception at runtime. To accomplish this, do the following:

0.    With the jazn-data.xml file still open in the editor, select the Overview tab.

1.    Click the (Users...) button in the upper-right corner of the Overview tab of the editor

2.    When the Edit JPS Identity and Policy Store dialog appears, ensure the Users page of the editor (indented under Identity Store and jazn.com realm name) is selected .

3.    Select the first user in the list ahunold.

4.    Select the existing value in the Credentials field and type welcome1

5.    Repeat steps 4 and 5 for each user in the list

6.    You can delete the two users whose names begin with DataBase_User_*

Note that you may have to update their passwords to have at least 8 characters before you're allowed to delete them.

7.    Finally, click (OK) to dismiss the dialog, and select Save All to save your changes.

13.   Clean the Application Compiled Artifacts

Before running the JUnit tests and the web application in the subsequent sections, first clean the application to remove any existing classes and XML files from the classpath to ensure you are only seeing the latest changes. To clean the application, select the SRDemoSampleADFBC workspace in the Application Navigator by clicking on the workspace list at the top. Then select Build | Clean All from the main menu. Acknowledge the alert if it appears.

14.     Update Tests and Help Text to Reflect New 8-Character Passwords

First, since we modified the password of every user from welcome to welcome1, we need to change the password used by the unit tests as well. In addition, the password appears on the login page as help text to remind users running the demo what the password of every use is. We'll update that help text as well.

To update the welcome password to be welcome1 in the unit tests, do the following:

·     Find the SRServiceTestAsManagerRole class in the UnitTests project (in the oracle.srdemo.tests.model.unittests package.

·     Search for welcome.

·     Change it to read welcome1

·     Perform this same change in the SRServiceTestAsTechnicianRole and SRServiceTestAsUserRole class as well.

Next, update the help text for the web application to reflect the change in password. To perform this change, do the following:

·     Select the UserInterface project

·     Select Navigate > Go to File... from the main menu (or press Ctrl+ Alt+ Minus)

·     Begin to type the first few letters of the UIResources.properties file to find it in the list, then press Enter to open the file to edit

·     Enter the string <b>welcome into the search field at the top of the code editor to find the translatable string containing the old welcome password.

·     Change this occurrence of welcome to be welcome1 instead.

·     If you also plan to run the demo in the Italian locale, perform the same change on the UIResources_it.properties file.

15.    Run the JUnit Regression Tests

To ensure everything is working correctly, run the JUnit regression tests. To do this, right-click the SRServiceAllTests.java class in the UnitTests project in the Application Navigator and choose Run . The JUnit Test Runner log window should 12 unit tests passing 100%.

If all of the tests failed, either you failed to clean the compiled application artifacts as described in the previous section, or you likely need to adjust the connection properties for the SRDemo application resource connection as described in the previous section. If you are using the Oracle 11g database, remember the password is now case-sensitive so you might need to change the SRDEMO user's password to ORACLE in uppercase. After cleaning the compiled output and/or adjusting the connection properties and testing the connection, try re-running the unit tests to see them pass.

16.   Run the Application

The application is now ready to run. Right-click the UserInterface project in the Application Navigator and choose Run again to login and put the demo through its paces. When your default browser appears with the login page, remember to use the new welcome1 password for each user account you try during your testing!