Skip to main content

ADF LifeCycle

Intro :

When a page is submitted and a new page requested, the application invokes both the ADF Faces page lifecycle, which extends the standard JSF request lifecycle, and the ADF page lifecycle.

The extended JSF lifecycle handles submitting the values on the page, validating component values, navigating pages, displaying components on the resulting page, and saving and restoring state.

The FacesServlet servlet manages the request processing lifecycle in JSF applications. It creates an object called FacesContext, which contains the information necessary for request processing, and invokes an object that executes the lifecycle.

The ADF page lifecycle handles preparing and updating the data model, validating the data at the model layer, and executing methods on the business layer. It uses the binding container to make data available for easy referencing by the page during the current page request.

With following example you will get the detailed idea about the ADF Lifecyle.


1.Suppose a web request for some page ex. http://server/yourapp/temp.jsp arrives from the client to the application server.





2.The ADFBindingFilter object looks for the ADF binding context in the HTTP session, and if it is not yet present, initializes it for the first time. It's work is to find the name of the binding context metadata file, and finding and constructing an instance of each data control.

3.The ADFBindingFilter object invokes the beginRequest() method on each data control participating in the request. This method gives the data control a notification at the start of every request so that it can perform any necessary setup.

4.The JSF Lifecycle object, which is responsible for orchestrating the standard processing phases of each request, notifies the ADFPhaseListener class during each phase of the lifecycle, so that it can perform custom processing to coordinate the JSF lifecycle with the ADF Model data binding layer.

5.The ADFPhaseListener object creates an ADF PageLifecycle object to handle each request and delegates appropriate before and after phase methods to corresponding methods in the ADF PageLifecycle class. If the appropriate binding container for the page has never been used before during the user's session, it is created.

6.The first time an application module(AM) data control is referenced during the request, it acquires an instance of the application module from the application module pool.

7.The JSF Lifecycle object forwards control to the page to be rendered.

8.The UI components on the page access value bindings and iterator bindings in the page's binding container and render the formatted output to appear in the browser.

9.The ADFBindingFilter object invokes the endRequest() method on each data control participating in the request. This method gives a data control notification at the end of every request, so that they can perform any necessary resource cleanup.

10.An application module data control uses the endRequest notification to release the instance of the application module back to the application module pool.

11.The user sees the resulting page in the browser.

Comments

Popular posts from this blog

Passivation and Activation in ADF (Application Module )

1. For performance reasons, ADF keeps a pool of application modules in memory. It tries to give each session the same application module as the session used during the last request; however, this might not be possible during peak load of your application. 2. In this case, ADF saves the application modules state in a database table so the application module can be used by another session. This is called passivation . 3. When the first session needs the application module again, its state is retrieved from the database process known as activation . 4. If you have made an error in your code and depend on some variable that is not persisted correctly when your application module state is stored, you will experience mysterious errors under high load.   Enable/Disable Application Module Pooling : Right-click on your application module, choose Configurations.By default, each application module has two configurations. Ensure that the one ending in …Local is selected and then click

Get modified rows from Entitiy Cache

To get the modified rows from entity cache we have getEntityState() method at EntityImpl class. Refer to my previous blog  Accessing EO impl methods from VO impl  where i am overriding the getEntityState() in EOimpl and calling it in VOImpl. We can use methods written or overridden in VOImpl class to AMImpl class. There are different states associated with an entity object. STATUS_UNMODIFIED STATUS_MODIFIED STATUS_NEW STATUS_DELETED STATUS_DEAD We have to check the state or row in our AmImpl class by using the VOImpl method and through this we can distinguish the rows present at vo. Add below code in AMImpl class along with my previous post. public void geCachedRowsCount(){         JobsVOImpl jobsVo = (JobsVOImpl)this.getJobsVO();         RowSetIterator iter = jobsVo.createRowSetIterator(null);             while(iter.hasNext()){             Row row = iter.next();             byte state = jobsVo.getEntityState(row);             System.out.println("Job_id -&

The file store "WLS_DIAGNOSTICS" could not be opened

WLS_DIAGNOSTIC ERROR weblogic.store.PersistentStoreException: [Store:280073]The file store "WLS_DIAGNOSTICS" could not be opened because it contained a file with the invalid version 1. A file of version 2 was expected. When you get this error while running your application on internal weblogic server delete the following file WLS_DIAGNOSTICS000000.DAT search the file in following path C:\jdev_work\system11.1.1.5.37.60.13\DefaultDomain this file is in DefaultDomain folder of your jdev. and delete the WLS_DIAGNOSTICS000000.DAT file . and run your applicatuon