|
Notes on Migrating ADF/Struts 10.1.2 Applications to 10.1.3
Coincidentally last week several users ran into an issue with JDeveloper 10.1.3, Struts, and JSP last week. Martin reports the issue in this OTN Discussion Forum Thread. I wanted to clarify the claims made therein regarding migrating ADF/Struts 10.1.2 applications to 10.1.3 as well as highlight the workaround to the bug they were experiencing.
You are not forced to touch your Struts DataAction code when migrating a 10.1.2 application to 10.1.3. We support both the existing approach as well as the new 10.1.3 approach that was required to unify the controller layer code for use by JSF, Struts, and Model 1 applications. You may have noticed that there is a new package structure oracle.adf.controller.v2 package tree with a "v2" version of some of the controller classes. Unfortunately this "v2" version was needed to avoid having to maintain parallel controller code going forward. It was important to us to have a unified ADF controller architecture that would support any of the controller approaches (including no controller) that we support. While we tried hard to design the 10.1.2 DataAction lifecycle after what we knew was coming in the JSF lifecycle, it wasn't exactly JSF, so this unification required a few changes.
As an example, you can download the 10.1.2 ADF Toy Store Demo (the specific version I refer to on this blog http://radio.weblogs.com/0118231/2005/11/01.html#a619 has the UIX viewcontroller layer removed to make 10.1.3 migration simpler until we release the UIX 10.1.3 support later this year). You can open it, and run it with no changes. There is migration that occurs to the struts-config.xml file and the UIModel files, but our testing has made sure this is a robust migration step. If your DataAction in 10.1.2 has a custom data action class, then your migrated struts-config.xml entry will have changed from something that looked like this before:
<action path="/yourcart"
className="oracle.adf.controller.struts.actions.DataActionMapping"
type="toystore.controller.strutsactions.YourCartAction"
name="DataForm"
parameter="/WEB-INF/jsp/yourcart.jsp"
unknown="false">
<set-property property="modelReference"
value="WEB_INF_jsp_yourcartUIModel"/>
<forward name="reviewcheckout" path="/reviewcheckout.do"/>
</action>
to something that will look like this in the migrated project in 10.1.3:
<action path="/yourcart"
className="oracle.adf.controller.v2.struts.actions.DataActionMapping"
type="oracle.adf.controller.v2.struts.actions.DataForwardAction"
name="DataForm"
parameter="/WEB-INF/jsp/yourcart.jsp"
unknown="false">
<set-property property="v1ActionClass"
value="toystore.controller.strutsactions.YourCartAction"/>
<forward name="reviewcheckout" path="/reviewcheckout.do"/>
</action>
You'll notice that the information about the "modelReference", which defined which UIModel.xml file was the binding container defintion for the current data action has gone missing. This information gets migrated into the migrated DataBindings.cpx file, where you'll see information like:
<Application ...>
<pageMap>
<!-- : -->
<page path="/yourcart.do" usageId="WEB_INF_jsp_yourcartUIModel"/>
<!-- : -->
</pageMap>
<pageDefinitionUsages>
<!-- : -->
<page id="WEB_INF_jsp_yourcartUIModel"
path="toystore.view.WEB_INF_jsp_yourcartUIModel"/>
<!-- : -->
</pageDefinitionUsages>
<dataControlUsages>
<!-- : -->
</dataControlUsages>
</Application>
which now is how the link is made between a view id (like "/foo.jsp" or "/foo.do" and a binding container definition XML file -- which we now call a page definition instead of a UIModel).
In the migrated struts-config.xml <action> entry, notice the appearance of the v1ActionClass property. This is part of the migration story that insures that if you had a custom data action class before, that it continues to run using the "v1" version of the DataAction lifecycle classes for upward compatibility.
That said, if you create a new data action in 10.1.3 it's going to inherit from the oracle.adf.controller.v2.PageController class.
NOTE: For new data actions and data pages, the name of the page controller class to use is no longer saved in the struts-config.xml file. Instead, it is noted in the ControllerClass property of the page definition XML file for that page/action.
This means that after allowing JDeveloper 10g to migrate your application, if you decide you want to migrate your data actions to the new "v2" lifecycle -- which I repeat is an optional choice -- the steps to migrate it would be:
- Remove the v1ActionClass element from the struts-config.xml
- Double-click on the data action (or right-mouse "goto code" on a data page) in the Struts page flow diagram to allow JDeveloper to create the new page controller class. This will automatically update the page definition XML file to add the ControllerClass property recording the name of the page controller class.
- Migrate the code from the "v1" data action class to the new "v2"-style page controller class.
The incorrect behavior you're seeing is Bug# 5063323 whose symptoms are that if any of the following methods are overridden in a custom 10.1.3 page controller subclass:
public void findForward(PageLifecycleContext context);
public void handleError(PageLifecycleContext context, Exception ex);
public boolean hasErrors(PageLifecycleContext context);
public void reportErrors(PageLifecycleContext context);
public boolean shouldAllowModelUpdate(PageLifecycleContext context);
then they are not being correctly engaged at runtime. Until we can fix this issue in the 10.1.3.1 maintenance release (hopefully even sooner via one of the service updates we'll begin doing this week via the new and improved 10.1.3 Check-for-Updates mechanism) the workaround as noted in the bug is to change your new page controller class to extend oracle.adf.controller.v2.struts.lifecycle.StrutsPageLifecycle instead of oracle.adf.controller.v2.lifecycle.PageController. The only downside to the workaround is that your custom page controller class then becomes Struts-specific, but in a Struts-based application that's not much of a downside in practice.
You can find more information in the JDeveloper online help that ships with the product (for some reason I cannot locate the same content in the OTN hosted on-line doc. Looking into why...) and visit the Help | Index menu option. In the help index, look for the entry:
ADF lifecycle
converting from previous releases
|
