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.”

JSF Portlet Bridge Presentations at the JSF Summit

Oracle’s Mike Freedman, the spec lead for JSR 301: Portlet 1.0 Bridge for JavaServer Faces 1.2 and JSR 329: Portlet 2.0 Bridge for JavaServer Faces 1.2 gives two presentations at the JSF Summit, in Orlando, FL.

Here are the abstracts:

 

 

Did you know that your JSF application is also a portlet?

The Portlet Bridge (JSR 301 or JSR 329) provides a Faces compatible runtime environment in a Java portlet environment enabling a JSF application to simultaneously be published as a web application and a portlet. This talk introduces you to the Portlet Bridge and shows you how to use it in your applications. Demonstrations are provided to illustrate concepts. Topics covered include:

• The difference between JSR 301 and JSR 329.
• Extending a Faces application so it also runs as a portlet.
• An overview of the bridge’s configuration flexibility to adapt to differing Faces and application environments.

The Portlet Bridge and the 2.0s

In the recent past both Java Portlets and JSF have published their 2.0 versions. This talk introduces you to how the major new features in each of these 2.0s are managed by the bridge. The Portlet Bridge provides a Faces compatible runtime environment in a Java portlet environment enabling a JSF application to simultaneously be published as a web application and a portlet. As a technology that sits between two others (the Java Portlet API and Faces), its capabilities expand as the controlling technologies are revised. Demonstrations are provided to illustrate concepts. Topics covered include:

• Portlet 2.0 shared render parameters
• Portlet 2.0 eventing
• Portlet 2.0 resource serving
• JSF 2.0 Ajax support

Build the Coolest WebCenter Application Ever – in 60 Minutes

Before Oracle OpenWorld 2008 kicks off in a week’s time in San Francisco, I plan to post a couple of highlights from the WebCenter space. This is the first one in the series.

At a conference of this size, one of the toughest challenges is how to best spend your time, what is really worth attending. My number 1 pick is hands down the WebCenter hands-on session. You get a chance to see and touch the product, experience it first hand, and last but not least get a chance to talk to people who build it: you can meet the WebCenter curriculum team.

When and Where?

Sunday, September 21, 2:30pm-3:30pm, Marriott, Golden Gate C1
Tuesday, September 23, 11:30am-12:30pm, Marriott, Golden Gate C1
Tuesday, September 23, 5:30pm-6:30pm, Marriott, Golden Gate C1

So – what is this year’s hands-on all about? It’s a brand new application built especially for the OOW WebCenter hands-on session that has one key objective: to impress you in less than an hour. The scenario is very original, quote from the hands-on document:

El Piju – Company Profile: Natural building is all about achieving sustainability through the use of minimally-processed, plentiful, and renewable resources as well as recycled or salvaged materials that produce healthy living environments. El Piju is your company for environmentally sensitive design and expert guidance on locating the resources you need to construct your sustainable home for the 21st century. What is your vision for your home or office? Let our team of ecologists, architects, and engineers help you make that vision a reality.
The El Piju application provides you with information about the company’s use of natural building materials and related projects. Once authenticated, you can select any of the construction materials used by El Piju, specifically, adobe, cob, cordwood, rammed earth, or straw bale, and access information about it. Search for articles, photographs, and other resources for that natural building material. Do you have a technical question or simply want to read what others have to say? El Piju’s site includes a discussion forum for each construction type. The application also includes a portlet that displays pictures with captions to provide visual examples of each building material. Browse through the pictures in the portlet by clicking the thumbnails.

How cool is this!

From a technical perspective, here are the topics covered in the hands-on session:

• Documents
• Discussions
• Tags
• Links
• Search
• Oracle Composer
• Portlets
• Inter-component communication

And last, but not least, the screen shot of the application.

And if you’re looking for a special mission, try to find out the story behind the company’s name.

2 Easy Steps to Implement Inter-Portlet Communication with WSRP 2.0

One of the most mysterious topics of the portal world is inter-portlet communication. Some of you expressed interest in portlet technologies in an earlier poll, so here we go…

Before the 2.0 versions of the portlet standards were ratified (WSRP 2.0, JSR 286), inter-portlet communication could only be achieved with some sort of a hack. Typical implementations included vendor-specific extensions on top of the portlet standards (breaking inter-operability), or portlets using a shared store to exchange information, such as the session context or a database. All of these workarounds required a hacker attitude.

The easiest way to try out the concept is by using two of the sample portlets from the WSRP Sample Portlet Producer: the Parameter Form and Parameter Display portlets. Here are the introductory steps you need to take, that are not related to inter-portlet communication, and you may well be familiar with:

1. Start up the preconfigured OC4J. First, point your browser to http://localhost:6688. Then click on the Sample Portlets link (http://localhost:6688/portletapp/info).
   
2. Copy the WSRP 2.0 WSDL end point URL (you find it on the bottom of the page) to your clipboard: http://localhost:6688/portletapp/portlets/wsrp2?WSDL.
   
3. Create an application in JDeveloper, based on the WebCenter Application Template.
   
4. Register the WSRP Sample Producer with your application.
   
   
   
5. Create a new jspx page, and drop the Parameter Form and Parameter Display portlets onto the page.
   

It takes only two steps to set up inter-portlet communication – and this is the actual meat of this post.

1. Wire the two portlets, so the parameters entered in the parameter form portlet are passed to the parameter display portlet.
   1. Switch to the page definition of the page (invoke the context menu in the middle of the page, and select Go to Page Definition. If the page definition doesn’t exist yet, let JDeveloper create it for you.
      
   2. Locate the two portlets in the Structure Pane, and expand the Parameters section to see the three WSRP 2.0 navigational parameters that these portlets provide. Notice that the portlet parameters are mapped to page variables. All you need to do is make sure that the portlet parameters of the Parameter Form Portlet are mapped to the same page variables as the parameter of the Parameter Display Portlet.
   3. Confirm your changes by taking a look a the source of the page definition.
      
2. Configure partial page refresh, so the parameter form display portlet refreshes when a new parameter is submitted in the parameter form portlet.
   1. On your jspx page select the Parameter Display portlet and locate Partial Triggers attribute. Point to the id of the Parameter Form portlet, for example portlet1.
      

That’s it!

Now run the application and enter some values into the Parameter Form portlet.

Click the OK button. The Parameter Display portlet should refresh with partial page refresh (PPR).

“And the crowd goes wild…” [B.H.]

What can I do with the Technology Preview 4 of WebCenter?

Just got back from my long vacation from Europe. I had several emails in my inbox asking: What are the types of things I can and cannot do with the Tech Preview of WebCenter? Here are a couple of simple things you can try out and provide us feedback on:

• Portlet creation: build and deploy JSR 168 portlets
• Portlet consumption: Consume WSRP 1.0 and WSRP 2.0 portlets
• JSF Portlet bridge: JSR 301: Portlet Bridge Specification for JavaServer Faces reference implementation: expose JSF applications through WSRP
• Content integration: test the new and improved JCR level 1 and level 2 support using the file system adapter
• Runtime customization: build applications featuring Composer, which allows privileged business users to add new resources to the pages and re-arrange to contents of the page
• Web 2.0 services: tagging and linking

If it sounds promising, give it a try!

Also wanted to make a note of things you cannot test without back-end services, which have not been released as part of the preview: threaded discussions, wiki, blog, presence, instant messaging, WebCenter Spaces.