February 28, 2021
Hot Topics:

Portal Federation with WebLogic Portal WRSP: Advanced Techniques

  • By Scott Nelson
  • Send Email »
  • More Articles »

Once the producer has published the remote pages and books, the consumer then needs to add them to the library. This is done in the same fashion as adding a WSRP portlet (as described in The Basics), only you select the Pages or Books section accordingly.

Click here for a larger image.

Figure 3: Remote Assets in the Portal Administration Tool

Oddly enough, the sequence of pages in a remote book is not maintained when consumed, so communication must be maintained between the producer developers and consumer portal administrators so that they can be arranged as desired in the consumer once the remote book has been added to the consumer desktop.

Passing Data Between Remote Portlets

Inter-Portlet Communication (IPC) is when an action in one portlet causes a reaction in another portlet. There is an example in the WLP documentation of how to have a receiver react to an Event fired by a sender. In this article we will take IPC one step forward and pass a run-time value from the sender to the receiver.

The important thing to remember when passing data from one remote portlet to another is that the request object is not shared between portlets. Although mildly annoying, this makes perfect sense because the collection of remote portlets on a given consumer page may not necessarily be from the same producer. There are multiple solutions to get around this, and the following example will use a non-standard approach to illustrate that there are times when requirements remind you that best practices are guidelines rather than rigid rules. I promise to cover the best practices approach in the next installment.

For this example, you are going to assume that your requirement is to maintain the value in session once it has been set. This is mighty convenient for your fictitious development project because you can accomplish this with the least amount of work. First, you will create a Serializable object to hold your value, and use a session singleton pattern just to keep the example simple:

package common.example;
import javax.servlet.http.HttpSession;

public class SharedData implements java.io.Serializable
   private String ipcValue1;
   private static final long serialVersionUID = 1518508811L;
   private static final String SESSION_DATA_ID =

   public static SharedData getInstance(HttpSession outerSession)
                                   new SharedData());
      return (SharedData)outerSession.
   private SharedData (){}
   public String getIpcValue1(){return ipcValue1;}
   public void setIpcValue1(String ipcValue1)
      {this.ipcValue1 = ipcValue1;}

Now, you will create a page flow controller that uses your SharedData object to store a value submitted by a form. Even though a formbean is potentially redundant for your needs, you'll cheat and use one anyways because the JSP wizards in Workshop make building a form using the form bean only a moment's work. As the "Advanced" in the tile of this article assumes, you already know how to build basic portlets; you'll just look at the relevant parts of the code (you can always download the example application to see the full code):

public Forward begin(IpcDemo3FormBean form)
   HttpServletRequest outerRequest = null;
   SharedData         sharedData   = null;

   outerRequest = ScopedServletUtils.getOuterRequest(getRequest());
   sharedData = SharedData.getInstance(outerRequest.getSession());

   if(form!=null && form.getIpcValue()!=null)
   return new Forward("default");;

The outerRequest reference may be unfamiliar if you haven't had to deal with request objects in WLP before. WLP breaks up the request object before providing it to portlets, scoping the request variables down to the portlet level. By using org.apache.beehive.netui.pageflow.scoping.ScopedServletUtils, you can gain access to the full request, which is what you need for another portlet to be guaranteed access to your object.

Page 2 of 3

This article was originally published on May 14, 2008

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date