Is JSR 168 Not Supported by WebCenter Patch Set 3?

This question may came up when you try to build a JSR 168 portlet or attempt to open one in JDeveloper 11g R1 PS3. In the latter case what happens is that your portlet gets automatically upgraded to a JSR 286 portlet. Given that JSR 286 supersedes JSR 168, most of the time this doesn’t cause problems. However, if for some reason you HAVE to create or edit a JSR 168 portlet without upgrading it, you’ll need to use a Patch Set 2 or earlier JDeveloper for it (or any other tool supporting JSR 168 portlets).

Despite the fact that JDeveloper automatically upgrades your portlets, deploying JSR 168 portlets to the Fusion Middleware 11g Patch Set 3 is fully supported.

This topic is covered by the Oracle Fusion Middleware Upgrade Guide for Oracle SOA Suite, WebCenter, and ADF:

15.4.2.1 About Upgrading JSR168 Portlet Producers to JSR286

Oracle WebCenter 10g supports Java portlets based on the Java Portlet Specification, JSR 168; Oracle WebCenter 11g supports Java portlets based on Java Portlet Specification version 2, or JSR 286. JSR 286 is an extension of JSR 168, and is backward compatible with JSR 168.

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.

In most cases, the upgraded portlets continue to work exactly as they did before. However, there are a few cases in which JSR 168 portlets function differently when upgraded to JSR 286; these portlets must invoke a JSR 168 compatibility mode to run under JSR 286.

In Oracle WebCenter 10g, a portlet producer application contains the portlet.xml and oracle-portlet.xml files. When you upgrade a portlet producer application, the oracle.portlet.xml file is deleted, and all its details are moved to portlet.xml. The navigation parameters stored in oracle.portlet.xml are converted into public render parameters and are added to portlet.xml. For information about how JSR 168 parameters are handled in an upgraded JSR 286-compliant portlet producer application, see Section 16.4, “Migration of JSR 168 Portlet Producers to JSR 286: Handling of Portlet Elements.”

What Container Does WebCenter Run on: WebLogic or OC4J?

I’ve been getting this question more and more often lately: which application server does WebCenter run on? WebLogic Server, acquired from BEA, or Oracle’s own OC4J?

The answer is very short and simple: WebCenter 10g runs on OC4J, WebCenter 11g runs (read: will run) on WebLogic Server.

The explanation is easy and straight forward too: in the 10g times the only Java EE container Oracle had, was OC4J. No problem there. When the 11g version ships, the entire Oracle Fusion Middleware 11g, including WebCenter will run on WebLogic Server.

Do I have to worry about migration, then?
No. You, as an application developer, see very little from the underlying container changes. In a nutshell, this is how you migrate an application built using JDeveloper 10.x: Open your workspace or project in JDeveloper 11g, and the automatically invoked migration tools will migrate your application, so it can run on the 11g WebLogic Server.

If there’s interest, as we get closer to the 11g release, I’ll be happy to post about the migration process as well. Just let me know… 😉