Posted on

JSR-286/JSR-168 Portlet Compatibility

I had a application which is based on JSR 168 portlet.We need to deploy it on webcenter 11g. What are key things which we should keep in mind.

-> your JSR 168 portlet WSRP 1.0 or 2.0 enabled.
-> WebCenter can only integrate WSRP enabled portlets
-> Portlet needs to have the valid web service endpoint to act as a WSRP endpoint.

When you use Oracle Enterprise Pack for Eclipse to import JSR 286 portlets into an existing web application that contains JSR 168 portlets or portlet which is based on JSR 168 built in 10g enviroment– the existing portlet.xml is upgraded to the JSR 286 schema. (Note that if you import portlets manually, by editing the schema files, this upgrade will not occur automatically.) In most cases, the JSR 168 portlets will continue to work exactly as they did before.

The WLP JSR 286 portlet container invokes a JSR 168 compatibility mode for a portlet if either of the following are true:

The portlet.xml in which the portlet is defined has an XML namespace that does not contain portlet-app_2_0 (it is a JSR168 portlet.xml file). If a file exists in the web application named /WEB-INF/oracle-portlet.xml, the WebCenter JSR 168 compatibility mode is invoked; otherwise, the WLP JSR 168 compatibility mode is not invoked.The container runtime option com.oracle.portlet.compatibilityMode is set to owlp168 (WLP JSR 168 compatibility mode) or owc168 (WebCenter JSR 168 compatibility mode). This allows JSR 286 portlets and JSR 168 portlets from WLP and/or WebCenter to co-exist in the same web application.Any hide-portlet entries with a value of true will automatically be converted to a false value for the container runtime option com.oracle.portlet.offerPortletOverWsrp if no value for that container runtime option is specified in the portlet.xml file.

When you upgrade a 10g portlet producer application, the WebCenter migrator deletes oracle-portlet.xml and upgrades portlet.xml. It converts the navigation parameters stored in oracle-portlet.xml into public render parameters and adds them to portlet.xml. If weblogic-portlet.xml exists, it is retained as is.

The migration of a JSR 168 portlet producer application to JSR 286 is fully automated; it does not require you to perform any additional manual steps. However, based on the warnings that may be displayed in the log panel during migration, you may want to make additional changes to portlets. The following tables describe how various parameters in the oracle-portlet.xml file of a JSR 168 portlet producer application are handled in portlet.xml of a JSR 286 portlet producer application.In Oracle WebCenter 10g, Oracle JSF Portlet Bridge is based on and conforms to JSR 301, whereas in Oracle WebCenter 11g, Oracle JSF Portlet Bridge conforms to JSR 329.
In JDeveloper 11g, when you open for the first time an existing portlet producer application containing JSR 168 portlets, portlets are automatically upgraded to be JSR 286 compliant. If the application is a portlet bridge application, it is further automatically upgraded to be JSR 329-compliant.

Happy coding with Techartifact

Posted on

Changing the WHERE clause or VO Query at runtime in Oracle ADF

Requirement- To change the WHERE clause of a query at run time:

Create a String containing the new WHERE clause. Do not include the word “WHERE”. If you do want to remove the WHERE clause entirely, use null. For example, either of the following could be appropriate definitions:

Pass this string into setWhereClause(). For example, if OrdVO is a variable containing the view object instance to be changed, you would call:

String whereClause = “ORDER_TOTAL > 500”;
String whereClause = null;
ordVO.setWhereClause(whereClause);

You can write this method in AmImpl.Java.For example

    public void executeSearchInstanceNoExp(String instanceNo) {
    String whereClause="instance_status = 'EXPIRED'";
    ViewObjectImpl searchVO = this.getEmployeeVo(); //relaventVO
    searchVO.setWhereClause(whereClause);
    searchVO.executeQuery(); //executeVO with Criteria

    }

you can add ORDER BY clauses of a query at runtime by calling setOrderByClause() on the view object.

String orderByClause = "ORDER_TOTAL";
ordVO.setOrderByClause(orderByClause);

Change the VO query at runtime or changing the Table or view at runtime

createViewObjectFromQueryStmt is used to change the query .You can write this method in AmImpl.Java

    public void executeSearchVoExp() {
       String sqlStatement= "select * from EMP";
        ViewObject dynamicVO = this.findViewObject("SearchByCustomerVo1");  
        dynamicVO.remove();  
        dynamicVO = this.createViewObjectFromQueryStmt("SearchByCustomerVo1", sqlStatement);  
        dynamicVO.executeQuery(); //executeVO with Criteria

    }