ADF Interview Questions - Set 7

Question: Explain briefly the life-cycle phases of JSF?

Answer: The six phases of the JSF application lifecycle are as follows:

1. Restore View: A request comes through the FacesServlet controller. The controller examines the request and extracts the view ID, which is determined by the name of the JSP page.
2. Apply request values - process events: The purpose of the apply request values phase is for each component to retrieve its current state. The components must first be retrieved or created from the FacesContext object, followed by their values.
3. Process validations - process events: In this phase, each component will have its values validated against the application’s validation rules.
4. Update model values - process events: In this phase JSF updates the actual values of the server-side model ,by updating the properties of your backing beans.
5. Invoke application - process events: In this phase the JSF controller invokes the application to handle Form submissions.
6. Render response: In this phase JSF displays the view with all of its components in their current state.

Question: Write code to access the current row and or the view object inside your bean?

Answer: Code to access the current row and or the view object inside your bean:

BindingContainer bc = BindingContext.getCurrent().getCurrentBindingsEntry();

DCBindingContainer dcbc = (DCBindingContainer) bc;

DCIteratorBinding lBinding = dcbc.findIteratorBinding("EmployeesViewIterator");

EmployeesViewRow row = (EmployeesViewRow) lBinding.getCurrentRow();

EmployeesView view = (EmployeesView) lBinding.getViewObject();

Question: What is Action Listener?

Answer: An action listener is a class that wants to be notified when a command component fires an action event. An action listener contains an action listener method that processes the action event object passed to it by the command component.

Question: What are mutable and immutable objects?

Answer: An immutable class is immutable, as in, it is not mutable. You cannot change it. If you have x::String, you can be absolutely 100% certain that x will never ever change ever (or at least, if it does, people are abusing the flexibility of your language and you have every right to tell them where to go).

A mutable class is not immutable. You can change it, other people can change it, and you can't rely on it being the same. It could be changed in another thread; you can't even be sure of it being in the same state from line to line unless you have good locking.

Question: What is Application module pooling and how can we handle it?

Answer: An application module pool is a collection of application module instances of the same type, such as an Orders application module or a Human Resources application module. This pool of application module instances is shared by multiple browser clients. The amount of time between submitting Web pages enables a smaller number of application module components to serve a larger number of active users. This reduces memory usage and improves performance.
This facility manages a configurable set of application module instances that grows and shrinks as the end-user load on your application changes during the day.

At any one time, the pool may contain application module instances that are partitioned into
three groups, based on their state. When the processing of a current HTTP request completes, the application module instance is checked back into the pool. If the AM instance has managed state, the pool keeps track that the AM is referenced by that particular session.
For example – We have pool of 5 Application module instances. After having request from multiple browsers, request will go to instance, which is available for time being. We have 3 state defined for appModule instances –
1- Available
2- Partially available- but referenced for preferred reuses by another active session that would be more efficient due to the managed state of the application module.
3- Unavailable- because it is being used at that very moment by a Web container thread

Note: Pools are created only for root application modules, not for nested ones that users access indirectly through a root application module.

In short –

Application module pooling:

• Enables users to share application modules
• Manages application state
• Provides the same instance or one with an identical state
when requested by an application with managed state

Question: How can we prevent unauthorised access to the ADF DC Model?

Answer: By using Bounded Task Flow

Question: How can we share AM for using same transaction?

Answer: By using AM Module Pooling.

Question: What are the MDS (Metadata Services)?

Answer: Metadata Services (MDS) is a feature provided by oracle to store customization and personalization information in a repository. The repository can either be stored in a database or in a file system as we will see.

For example if a screen has a table, this table has 8 columns, and there are a user (User1) want to see only 4 columns and hide the others. When User1 login again he want to see last changes which he make (see only 4 columns), the user can see any changes he make in the screen only if you apply MDS to your application.