Query Binding Property: InitialQueryOverridden

I was working on a requirement, wherein, we had to launch a search page by applying a view criteria, which is different from the one in the search panel. While debugging, it was observed that, when the view criteria was applied, VO has been populated with the rows. But the UI is not displaying the records of the pre-executed query.

By default, Query binding will follow 'AutoQuery-or-ClearRowSet' behavior (which is based on the view criteria attribute). Thus, even though we have executed the query well before the page is launched, query Binding is executing the Clear Rowset (in my case it is Clear Rowset). To override the default 'AutoQuery-or-ClearRowSet' behavior , one can use the query binding's property InitialQueryOverridden.

When this property is set to true, i was able to see the results of the pre-executed query.

RowCount Vs EstimatedRowCount Vs FetchedRowCount

getRowCount():
Method getRowCount() retrives all the records from View Object by executing ViewObject Query.The count is calculated by traversing the Viewobject using next() method until the
last record is retrived. This method hinders the performance of application incase of VO with large number of rows.

getEstimatedRowCount():
To obtain a quicker count, getEstimatedRowCount() can be used. Method getEstimatedRowCount() actually retrives the count by hitting getQueryHitCount() which runs the select count(*) on the VO query.

getFetchedRowCount():
Method getFetchedRowCount() counts the number of rows from the Result Set.if getFetchedRowCount()

Retrive ViewCriteria from the QueryEvent

 public void handleQuery(QueryEvent queryEvent) {
        if(queryEvent.getSource() instanceof RichQuery) {
            DCBindingContainer bindingContainer = (DCBindingContainer) BindingContext.getCurrent().getCurrentBindingsEntry();
            QueryDescriptor queryDescriptor = queryEvent.getDescriptor();
            Object executableBinding = bindingContainer.findExecutableBinding("TestSearchCriteriaQuery");
            String criteriaName = queryEvent.getDescriptor().getName();
            ViewCriteria vc = JUSearchBindingCustomizer.getViewCriteria((DCBindingContainer)executableBinding, criteriaName);
            //......
 }
    }

A Date with WLS Security

A Principal is an identity assigned to a user or group as a result of Authentication.
After successful authentication, principals are stored and signed in a Subject for future use.
A Principal Validation provider signs the Principals and the Authentication Provider Login module populates the subject with the principals. Later, when a caller attempts to access a principal stored in a subject,Principal Validation Provider verifies that the principal has not been altered since it was signed, and the principal is returned to teh caller.

A Security Policy is created when we define an association between a Weblogic resource and users/groups.A Weblogic resource has no security until a security policy is assigned to it.
Security Policies are stored in an Authorization Provider's Database. By Default, Authorization providers are configured and Security Policies are stored in the embedded LDAP server.

Security realm comprises mechanisms for protecting Weblogic resources.Security Realm consists of:
Security providers
Users
Groups
Security Roles
Security Policies

A user must be defined in a security realm inorder to access any weblogic resource belonging to that realm.When the user tries to access a weblogic resource,WLS tries to authenticate and authorize the user by checking the security role assigned to the user in the security realm and the security policy of the resource.

When a User wants to access weblogic server resource, authentication happens through the JAAS login Module to the Authentication Provider configured in the security realm.

If Weblogic can identify the user based on the Credentials, WLS associates the principal assigned to a user, with a thread that executes code on behalf of the user.