Migrating the 10.1.3 SRDemo Sample to 11g Tech Preview 4
Migrating the 10.1.3 SRDemo
Sample to 11g Tech Preview 4
Author: Steve Muench, ADF Development
Team Date: May 3, 2008 Revision 1.2 (Revision History)
Abstract
This paper outlines the steps to migrate an ADF 10.1.3 JSF
application using ADF Faces components to JDeveloper 11g. Using the SRDemo
Sample application as a hands-on example, it explains the automatic migration
support and leads you step-by-step through the temporary post-migration steps
required in the OTN Technology Preview 4 release due to known
issues.
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 Technology
Preview 4 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 Technology
Preview 4 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
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 [2] 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.
NOTE:
You can find additional
details on the ADF Faces to Trinidad migration path implemented by the
Migration Wizard on the
ADF to
Trinidad Wiki page [3].
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 Technology Preview 4
Migration of
10.1.3 applications was not supported using the previous JDeveloper 11g
Technology Preview 1 release. Please download the Studio
Edition of JDeveloper 11g Technology Preview 4 from the
JDeveloper
product center on OTN [4] 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.DROP5_GENERIC_071218.2321.4796, which is the
"Technology Preview 4" release mentioned above.
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 Technology Preview
4 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) [5] 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 Technology Preview 4
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:
On the
Welcome page, click
(Next)
On the
Confirmation page, take the default choice of
Yes to the Do you want to migrate these
files? radio group, then click
(Next)
On the first
UserInterface.jpr page, leave the Migrate to
Webapp 2.5 checkbox checked. Notice that this choice also implies
that the Convert JSF 1.1 to 1.2 checkbox is checked. Also
leave the Convert JSTL 1.0 to 1.2 checkbox checked, then
click (Next).
On the
second UserInterface.jpr page, leave the Migrate
to Trinidad checkbox checked, then click
(Next).
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 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:
Click on the workspace dropdown list in the Application Navigator
to select the SRDemoSampleADFBC workspace
Choose Run | Rebuild Application
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
CtrlG.
On line 137, change:
Set keySet = getHistoryTable().getSelectionState().getKeySet();
to this:
Set keySet = getHistoryTable().getSelectedRowKeys();
Finally, rebuild the application to ensure all of the compilation errors
have been resolved. To do this, perform these steps:
Click on the workspace dropdown list in the Application Navigator
to select the SRDemoSampleADFBC workspace
Choose Run | Rebuild Application
from the main menu.
The application should now be free of any compilation errors. A few
deprecation warnings (10 total) are expected and are OK. [Bugs 6361611,
6408481]
5 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!)
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.
6 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, select the
Source tab at the bottom of the editor, and locate the
following line in the source.
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!)
Change Remaining Usages of Table Row Variable Outside
of the Core Table Contents
In the Trinidad
implementation shipped with this preview, only UI components in the main
<tr:table> contents can reference the table's
row variable. The table's row variable is
out of scope for any of the table's other facets, as well as on the rest of the
page. Since the ADF Faces 10.1.3 UI component children of an
<af:tableSelectOne> or <af:tableSelectMany>
component in the selection facet of an
<af:table> are migrated to be Trinidad UI components inside
the actions facet of the <tr:table>, this
means that any attributes that contain EL expressions like
row.rowKeyStr or
row.SomeAttributeName will not
work correctly after migration, where row is the name of the
table's row variable.
In the Technology Preview 4 release,
references to #{row.rowKeyStr} in the selection facet are
automatically migrated to an alternative expression that references the
rowKeyStr from the table binding instead. However, other
references to the row variable in the selection facet need
to be changed by hand. For example, these might be references to attribute
values in the current row like #{row.SomeAttrName}. To
address this current limitation, you need to change the affected usages of the
table's row variable to instead reference the ADF table
binding to access the attribute value from the currently selected row. Perform
the following change:
In page ./app/staff/SRStaffSearch.jspx, inside the
actions facet of the <tr:table>, find the
two occurrences of row.UserId as follows:
The refererence to
#{row.UserId} that appears inside the
<tr:column> inside the main content of the
<tr:table> does not need to be changed,
as the table's row variable is valid
there.
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:
Open the
SRMain.jspx and select the Source tab
to see the page source
Search for the
<tr:panelBox> tag with
id="addNotesPanel"
Inside
this panel, find the <tr:commandButton> for the cancel
operation. It will look like this:
7 Manual Changes Required to Page Definitions
After Migration
Perform the following changes:
Adjust Reference to Table Row Variable in Action Binding
Parameter Expression
After migration, the
SRList.jspx page has a (View) and
(Edit) button, both of which are bound to trigger the
execution of the setCurrentRowWithKey action binding. Since
these buttons are not inside the main contents of the Trinidad
<tr:table> a reference to the table's row
variable made by the action binding will evaluate to null.
Therefore, we need to also adjust the row.rowKeyStr of the
<NamedData> action binding parameter in the page defintion for
this setCurrentRowWithKey action binding.
To
perform this, do the following:
Right-click
page ./app/SRList.jspx in the Application Navigator and choose
Go to Page Definition.
Expand the setCurrentRowWithKey action binding node in
bindings section of the
Structure Window
Select the
rowKey parameter child node inside the
setCurrentRowWithKey action binding
In the Property Inspector, change the the
NDValue property value expression from
${row.rowKeyStr} to
${bindings.LoggedInUserServiceRequests.rowKeyStr}
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]}
8 Replace adfFacesContext References
with Trinidad requestContext
In this Technology Preview 4 release,
the migration wizard does not yet automate a required substitution of the
adfFacesContext by the Trinidad equivalent
requestContext, 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.
Ensure the [ x ]Regular
Expressions checkbox is checked.
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
[ ]Recurse
into Zip and Jar Files
[ ]Match Whole Word Only
[ ]Preview Change
Then click
(OK).
9 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:
Change directory to
./SRDemoSampleADFBC/DatabaseSchema/scripts
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
As user SYSTEM, run the
build.sql script:
sqlplus system/manager @build.sql
As user SRDEMO,
run the createContextPackage.sql script and the
createContextPackageBody.sql script.
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.
10 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)
11 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 Tools | ADF
Security Wizard from the main menu.
On the Authentication page of the wizard,
select the Configure ADF Security for A Web Application
radio group button, and leave the Enforce Authorization
and Redirect Upon Successful Authentication checkboxes
unchecked. Then press (Next>)
On the Identity Store page, select the
Lightweight XML Identity Store option, and click
(Next>)
On the
XML Identity Store page, leave the default
Realm value of jazn.com and click
(Next>)
On the
Credential Store page, ensure the Enable
Credential Store radio group button is selected, then press
(Next>)
On the
Policy Store page, select the No Policy
Store option, and click
(Next>)
On the
Anonymous Provider page, select the No Anonymous
Provider option, and click
(Next>)
On the
Login Modules page, the
idstore.loginmodule should already appear in the
Selected Login Modules list. Since that's the only one we
need, just click (Next>)
On the Login page, notice that the wizard has sensed
that Form-Based Authentication is already in use in the migrated project, so
the Form-Based Authentication radio group button should be
already selected, and the name of the
infrastructure/SRLogin.jspx page should appear both as the
Login Page and as the Error Page.
Then, click (Next>)
On
the Resources page, it presents the web page security
constraints that are already in effect in the project. Just leave these as they
are and click (Next>).
On the Summary page, click
(Finish)
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 from the
previous jazn-data.xml being used by the SRDemo in the ConfigurationData
directory to the new jazn-data.xml file created by the ADF Security Wizard
above, do the following:
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.
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.
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.
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> and </jazn-data> tags, 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.
12 Regenerating Connections for Embedded OC4J
The last
migration step is required for running on the embedded OC4J server, and
involves regenerating the application-specific data-sources.xml file for the
SRDemo application resource connection. The 10.1.3 version of the demo shipped
with the workspace-level preference disabled to automatically generate the data
sources, so we need to re-enable it. To do this, follow these steps:
Select Tools |
Preferences... from the main menu
When the Preferences dialog appears, select the
Run panel in the tree at the left
On the Run panel, click the
(Embedded OC4J Server Preferences...)
button
In the Embedded OC4J Server
Preferences Dialog, select the Data Sources
node that is indented inside of the Current
Workspace(SRDemoSampleADFBC) node in the tree.
Check the Update existing data-source
elements checkbox
Check the
Auto-update data-sources.xml when running or deploying to
OC4J checkbox
Then, click
(OK) to dismiss the dialog and (OK)
again to close the Preferences dialog,
too
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 Run | Clean
Application from the main menu. Acknowledge the alert if it
appears.
14 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 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.
15 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.
NOTE:
For your convenience, you
can download a version of the
11gOTN4-migrated
SRDemo Sample (ADFBC Version) [6] that has been migrated following the
instructions in this document. However, you will still need to follow the steps
in above sections before running the demo: