Skip to main content

ADF Faces configuration

By

ADF Faces configuration options are defined in the web.xml file using <context-param> elements.

 STATE_SAVING_METHOD :

 The JSF parameter javax.faces.STATE_SAVING_METHOD identifies where the state of the view is stored between requests. 
By default, the state is saved in the servlet session. Set the STATE_SAVING_METHOD parameter to client in the context-param stanza of the web.xml file, so that JSF stores the state of the entire view in a hidden field on the rendered page. If you do not, then JSF may attempt to cache that state, 
which is not serializable, in the session object.

 <context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>client</param-value>
</context-param>
CLIENT_STATE_METHOD : 

 org.apache.myfaces.trinidad.CLIENT_STATE_METHOD specifies the type of client-side state saving to use when client-side state saving is enabled by using javax.faces.STATE_SAVING_METHOD. 

 The values for CLIENT_STATE_METHOD are:
token : (Default) Stores the page state in the session, but persists a token to the client. The simple token, which identifies a block of state stored back on the HttpSession object, is stored on the client. This enables ADF Faces to disambiguate the same page appearing multiple times. Failover is supported.

 all : Stores all state information on the client in a (potentially large) hidden form field. It is useful for developers who do not want to use HttpSession.

 Because of the potential size of storing all state information, it is recommended that you set client-state saving to token.
Framebusting :

 Use the oracle.adf.view.rich.security.FRAME_BUSTING context parameter to use framebusting in your application. Framebusting is a way to prevent clickjacking, which occurs when a malicious web site pulls a page originating from another domain into a frame and overlays it with a counterfeit page, allowing only portions of the original, or clickjacked, page (for example, a button) to display. 
When users click the button, they in fact are clicking a button on the clickjacked page, causing unexpected results.

 For example, say your application is a web-based email application that resides in DomainA, and a web site in DomainB clickjacks your page by creating a page with an IFrame that points to a page in your email application at DomainA. When the two pages are combined, the page from DomainB 
covers most of your page in the IFrame, and exposes only a button on your page that deletes all email for the account. Users, not realizing they are actually in the email application, may click the button and inadvertently delete all their email.

 Framebusting prevents clickjacking by using the following JavaScript to block the application's pages from running in frames:
top.location.href = location.href;

 Valid values are:

 always : The page will show an error and redirect whenever it attempts to run in a frame.

 differentDomain : The page will show an error and redirect only when it attempts to run in a frame on a page that originates in a different domain (the default).

 never : The page can run in any frame on any originating domain.
More on ADF Faces Configuration

Comments

Post a Comment

Popular posts from this blog

Passivation and Activation in ADF (Application Module )

By
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
1 comment
Read more

Get modified rows from Entitiy Cache

By
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 -&
2 comments
Read more

The file store "WLS_DIAGNOSTICS" could not be opened

By
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
1 comment
Read more