Dear Reader,

I was wondering if the following is expected behavior or is perhaps a bug.

Using JDev 10.1.3, Struts, ADF and jsp. In the 'old' version of JDeveloper (JDev 10.1.2) when you for instance wanted to modify error handling for 1 thing you could override: reportErrors(DataActionContext ctx) of DataForwardAction and do your custom things there.

Now when moving to the new version, you need to extend PageController - set the new class in your data definitions file (of the jsp page). My assumption would then be, as it has the reportErrors(PageLifecycleContext) method - that one would be called instead (see also migrating JDev 10.1.2 to JDev 10.1.3, the struts part in the help). However, it does not get called at all. Instead only the phase-methods are called (which is of course correct), but methods like hasErrors(..) and reportErrors(..) are called inside the StrutsPageLifecycle class. So it seems you can't override reportErrors in the PageController class. I could fix it, by doing the work in the prepareRender(..) method (as inside that one hasErrors(..) and reportErrors(..)) are called.

Is this correct behavior? And if so, why are methods like reportErrors(..) not made private (or something similar) as it looks like these are 'dummy' methods as they are not called.

Best Regards,
Martijn

Hi Fred,

Yes you need to migrate your code to the changed ADF framework. There's a Help topic available which tells you how to do (from 10.1.2 to 10.1.4). Basically your code must move to a subclass of PageController. Shale is not supported yet (as far as I know).

As for the behavior I described earlier, Steve will get to this post.

Best Regards,
Martijn

Martin,

First a clarification. 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.

The incorrect behavior you're seeing is Bug# 5063323 (just filed yesterday), whose symptoms are that if any of the following methods are overridden in a custom 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.

Thank you for your answer Steve. It's true you don't have to migrate your old 10.1.2 code to 10.1.3, but I am starting a new project for a customer - and faces is not an option (yet), thus I wanted to use the same custom code in the new project - so I had to migrate in order to be able to use it with the v2 version. I was not very clear in that, my apologies.
As for the coming update: Is it sufficient to redeploy the ADF libraries then (after the update), on the Oracle application server to make it compatible?

Fred: Your old code can remain as it was as Steve explained. If you have new code: you should extend StrutsPageLifecycle (for now due to the bug mentioned by Steve) and move your old calls to the appropriate methods there. e.g.:

// old
protected void handleLifecycle(DataActionContext ctx) throws Exception {
   super.handleLifecycle(ctx);
   // Your code here
}
 
// new
public void prepareModel(PageLifecycleContext ctx) {
  // Your code here, as it must be before this phase
  super.prepareModel(ctx)
}

A few methods have changed, others you can't replace directly. But the JDeveloper Help tells you which methods and how to migrate them. Just look under 'adf lifecycle' in the index of the help.

Best Regards,
Martijn

I've updated the entry on my blog with the pointer to the topic in the online doc that talks about the migration. I couldn't find it in the OTN hosted version of the online doc for some reason...

http://radio.weblogs.com/0118231/stories/2006/02/28/notesOnMigratingAdfstruts1012ApplicationsTo1013.html

You mention bug# 5063323 to be corrected in the new updates.
I checked the 2 available JDev 10.1.3. updates and I didn't see this bug in the corrected bug list?

We are planning to acquire OAS 10.1.3g which can only be deployed with JDev 10.1.3.
For the time being we are installing a linux test server.
So we need to migrate our customized Struts/ADF 10.1.2 code to JDev 10.1.3

As I understand it we won't be able to use the designer with our custom BaseDataForwardAction class.

My question is this bug an ADF library bug?
Is this bug part of the ADF runtime libraries that come with the OAS 10.1.3g J2EE version?

If yes then we are really stuck.

Regards

Fred

Hi,

I have trouble running my migrated 10.1.2 Struts/ADF app see thread:

http://forums.oracle.com/forums/thread.jspa?threadID=390958

so I decided to migrate the 10.1.2 ToyStore demo stated in your message but that doesn't work either (other type of errors).
In order to understand what's wrong in my app I would like to analyze a working migrated 10.1.2 struts/ADF app.

Stack trace:

[Starting OC4J using the following ports: HTTP=8988, RMI=23891, JMS=9227.]
**** Unable to obtain password from principals.xml. Using default.
E:\fred\jdev1013\jdev\system\oracle.j2ee.10.1.3.36.73\embedded-oc4j\config>
E:\fred\jdk1.4.2\bin\javaw.exe -ojvm -classpath E:\fred\jdev1013\j2ee\home\oc4j.jar;E:\fred\jdev1013\jdev\lib\jdev-oc4j-embedded.jar -Djbo.debugoutput=file -Xverify:none -DcheckForUpdates=adminClientOnly -Doracle.application.environment=development -Doracle.j2ee.dont.use.memory.archive=true -Doracle.j2ee.http.socket.timeout=500 -Doc4j.jms.usePersistenceLockFiles=false oracle.oc4j.loader.boot.BootStrap -config E:\fred\jdev1013\jdev\system\oracle.j2ee.10.1.3.36.73\embedded-oc4j\config\server.xml
[waiting for the server to complete its initialization...]
06/05/26 11:44:22 oracle.classloader.util.AnnotatedClassFormatError: MBeanServerEjbHome_StatefulSessionHomeWrapper1

Invalid class: MBeanServerEjbHome_StatefulSessionHomeWrapper1
Loader: system.root:0.0.0
Code-Source: /E:/fred/jdev1013/jdev/system/oracle.j2ee.10.1.3.36.73/embedded-oc4j/application-deployments/admin_ejb/deployment-cache.jar
Configuration: <ejb> in wrappers

Dependent class: com.evermind.server.ejb.deployment.SessionBeanDescriptor
Loader: oc4j:10.1.3
Code-Source: /E:/fred/jdev1013/j2ee/home/lib/oc4j-internal.jar
Configuration: <code-source> in META-INF/boot.xml in E:\fred\jdev1013\j2ee\home\oc4j.jar

06/05/26 11:44:22 at oracle.classloader.PolicyClassLoader.findLocalClass (PolicyClassLoader.java) [/E:/fred/jdev1013/j2ee/home/lib/pcl.jar (from system property java.class.path), by sun.misc.Launcher$AppClassLoader@10]
at oracle.classloader.SearchPolicy$FindLocal.getClass (SearchPolicy.java:167) [/E:/fred/jdev1013/j2ee/home/lib/pcl.jar (from system property java.class.path), by sun.misc.Launcher$AppClassLoader@10]
at oracle.classloader.SearchSequence.getClass (SearchSequence.java:119) [/E:/fred/jdev1013/j2ee/home/lib/pcl.jar (from system property java.class.path), by sun.misc.Launcher$AppClassLoader@10]
at oracle.classloader.PolicyClassLoader.internalLoadClass (PolicyClassLoader.java:1660) [/E:/fred/jdev1013/j2ee/home/lib/pcl.jar (from system property java.class.path), by sun.misc.Launcher$AppClassLoader@10]
at oracle.classloader.PolicyClassLoader.loadClass (PolicyClassLoader.java:1621) [/E:/fred/jdev1013/j2ee/home/lib/pcl.jar (from system property java.class.path), by sun.misc.Launcher$AppClassLoader@10]
at oracle.classloader.PolicyClassLoader.loadClass (PolicyClassLoader.java:1606) [/E:/fred/jdev1013/j2ee/home/lib/pcl.jar (from system property java.class.path), by sun.misc.Launcher$AppClassLoader@10]
at java.lang.ClassLoader.loadClassInternal (ClassLoader.java:302) [jre bootstrap, by jre.bootstrap]
at java.lang.Class.forName0 (Native method) [unknown, by unknown]
at java.lang.Class.forName (Class.java:219) [jre bootstrap, by jre.bootstrap]
at com.evermind.server.ejb.deployment.SessionBeanDescriptor.createHomeInstance (SessionBeanDescriptor.java:443) [/E:/fred/jdev1013/j2ee/home/lib/oc4j-internal.jar (from <code-source> in META-INF/boot.xml in E:\fred\jdev1013\j2ee\home\oc4j.jar), by oc4j:10.1.3]
at com.evermind.server.ejb.EJBPackageDeployment.getHomeInstanceCore (EJBPackageDeployment.java:1136) [/E:/fred/jdev1013/j2ee/home/lib/oc4j-internal.jar (from <code-source> in META-INF/boot.xml in E:\fred\jdev1013\j2ee\home\oc4j.jar), by oc4j:10.1.3]
at com.evermind.server.ejb.EJBPackageDeployment.getHomeInstance (EJBPackageDeployment.java:1189) [/E:/fred/jdev1013/j2ee/home/lib/oc4j-internal.jar (from <code-source> in META-INF/boot.xml in E:\fred\jdev1013\j2ee\home\oc4j.jar), by oc4j:10.1.3]
at com.evermind.server.ejb.EJBPackageDeployment.bindRemoteHome (EJBPackageDeployment.java:533) [/E:/fred/jdev1013/j2ee/home/lib/oc4j-internal.jar (from <code-source> in META-INF/boot.xml in E:\fred\jdev1013\j2ee\home\oc4j.jar), by oc4j:10.1.3]
at com.evermind.server.ejb.EJBPackageDeployment.bindHomes (EJBPackageDeployment.java:442) [/E:/fred/jdev1013/j2ee/home/lib/oc4j-internal.jar (from <code-source> in META-INF/boot.xml in E:\fred\jdev1013\j2ee\home\oc4j.jar), by oc4j:10.1.3]
at com.evermind.server.ejb.EJBContainer.postInit (EJBContainer.java:1010) [/E:/fred/jdev1013/j2ee/home/lib/oc4j-internal.jar (from <code-source> in META-INF/boot.xml in E:\fred\jdev1013\j2ee\home\oc4j.jar), by oc4j:10.1.3]
at com.evermind.server.ApplicationStateRunning.initializeApplication (ApplicationStateRunning.java:210) [/E:/fred/jdev1013/j2ee/home/lib/oc4j-internal.jar (from <code-source> in META-INF/boot.xml in E:\fred\jdev1013\j2ee\home\oc4j.jar), by oc4j:10.1.3]
at com.evermind.server.Application.setConfig (Application.java:391) [/E:/fred/jdev1013/j2ee/home/lib/oc4j-internal.jar (from <code-source> in META-INF/boot.xml in E:\fred\jdev1013\j2ee\home\oc4j.jar), by oc4j:10.1.3]
at com.evermind.server.Application.setConfig (Application.java:309) [/E:/fred/jdev1013/j2ee/home/lib/oc4j-internal.jar (from <code-source> in META-INF/boot.xml in E:\fred\jdev1013\j2ee\home\oc4j.jar), by oc4j:10.1.3]
at com.evermind.server.ApplicationServer.initializeSystemApplication (ApplicationServer.java:1480) [/E:/fred/jdev1013/j2ee/home/lib/oc4j-internal.jar (from <code-source> in META-INF/boot.xml in E:\fred\jdev1013\j2ee\home\oc4j.jar), by oc4j:10.1.3]
at com.evermind.server.ApplicationServer.initializeAutoDeployedApplications (ApplicationServer.java:1467) [/E:/fred/jdev1013/j2ee/home/lib/oc4j-internal.jar (from <code-source> in META-INF/boot.xml in E:\fred\jdev1013\j2ee\home\oc4j.jar), by oc4j:10.1.3]
at com.evermind.server.ApplicationServer.setConfig (ApplicationServer.java:922) [/E:/fred/jdev1013/j2ee/home/lib/oc4j-internal.jar (from <code-source> in META-INF/boot.xml in E:\fred\jdev1013\j2ee\home\oc4j.jar), by oc4j:10.1.3]
at com.evermind.server.ApplicationServerLauncher.run (ApplicationServerLauncher.java:113) [/E:/fred/jdev1013/j2ee/home/lib/oc4j-internal.jar (from <code-source> in META-INF/boot.xml in E:\fred\jdev1013\j2ee\home\oc4j.jar), by oc4j:10.1.3]
at java.lang.Thread.run (Thread.java:534) [jre bootstrap, by jre.bootstrap]

I'm really stuck now!

Regards

Fred

Please use a separate thread for an unrelated issue, rather than posting a reply to an existing thread. Thanks.