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

New Features in JSF 2.0

With many new features, JSF 2.0 is an evolution from 1.2, but it’s also a step forward—for example, in
terms of PDL, where Facelets is preferred to JSP. New features of JSF 2.0 include the following:

• An alternative viewing technology to JSP based on Facelets

• Easier navigation between pages with implicit and conditional navigation

• JSF has been using POST HTTP requests intensively; this new release brings back GET requests as a first-class citizen (allowing users to bookmark pages)
• A new resource-handling mechanism (for images, CSS, JavaScript files, and so on)

• Additional scopes (view scope, flash and component scope)

• Easy development with annotations for managed beans, renderers, converters,validators, and so on.

• Reducing XML configuration by exploiting annotations and configuration by exception (faces-config.xml is optional)

• Ajax support

• Better error handling (provides information such as line numbers and not just a stack trace)

• Easy component development

I will also point some differences between JSF 1.2 and JSF 2.0
JSF 1.2 JSF 2.0
Pure JSF without any bells and whistles specific to JSF 2 (Ajax stuff and such) – the difference while in JSF 2.0 this has become mostly unnecessary. But that is not really where
won’t be that great. What you have additionally in JSF 1.2 is the need to declare everything i you lose the time.Only when you start to think about custom components will JSF
n a faces-config.xml file. 2.0 give you faster development cycle because it has made easier through facelets.
It take little more time than JSF 2.0 It can save your time compared to JSF 1.2