Wednesday Feb 16, 2011

Portlet Container and JSF Portlet Bridge Projects migrated

The Portlet Container and JSF Portlet Bridge Projects have been migrated from CollabNet hosted infrastructure to Kenai hosted infrastructure.

The new URLs are

Portlet Container Project : http://portlet-container.java.net

JSF Portlet Bridge Project: http://jsfportletbridge.java.net

The previous URLs are being redirected to the new URLs.

All the links and downloads have been appropriately modified. If anything is missing, please let me know. Thanks.


Friday Sep 03, 2010

OpenPortal Portlet Container 2.1.2 and NetBeans Portal Pack 3.0.4 released

We are pleased to announce the release of OpenPortal Portlet Container 2.1.2 and NetBeans Portal Pack 3.0.4.

For the details regarding NetBeans Portal Pack 3.0.4 you can check Satya's blog.

The OpenPortal Portlet Container 2.1.2 has few enhancements and bug fixes. Following is brief list of changes that went into this release. Check the User Guide for more details

  • support for the install and portlet deployment on Oracle WebLogic, GlassFish V3, JBoss Application Server and Jetty
  • ability to embed a portlet in a JSP using tag libraries
  • now there is an option to store portlet driver data and portlet preferences to the database.
It is recommended that you uninstall previous versions before installing this release.

Following developer tools are available to develop, deploy and test portlets on the OpenPortal Portlet Container 2.1.2

If you have questions on how to use the OpenPortal Portlet Container and other comments/suggestions/requests, we urge you to join the users@portlet-container.dev.java.net alias.

Please report any issues that you encounter while trying OpenPortal Portlet Container to issues@portlet-container.dev.java.net.

Monday Nov 30, 2009

Resetting the JSF Portlet State

Consider a JSF Portlet having a navigation(what is a JSF app without navigation!!), for example a Search JSF Portlet. It has two pages, "Search Criteria Page" and "Search Results Page".  After you enter the criteria on "Search Criteria Page" and click submit, you will get a "Search Results Page". Add this JSF Portlet on a page in Web Space or Liferay. Now visit some other page and comeback to the page on which you added the JSF Portlet, you will see that it is showing "Search Results Page", i.e the state is retained. This is as per spec and is the correct behaviour. What if you want to see "Search Criteria Page" everytime you visit the page. This can be achieved as follows.

1. In your JSF Portlet, add the following init parameter in the portlet.xml

        <init-param>
            <name>com.sun.faces.portlet.CLEARING_STATE_ENABLED</name>
            <value>true</value>
        </init-param>

2. In Web Space / Liferay, Click on "Manage Pages"

Manage Pages Drop Down

3. Select the page that has JSF Portlet(in this example, i have it on "jsftest" page). In the "Query String" textfield, enter the value com.sun.faces.portlet.CLEAR_STATE=true. Save the page.

Manage Pages

Now whenever you visit the page you will see the "Search Criteria Page". But if you are doing any action on any other portlet on that page, "Search JSF Portlet" will retain the state. It will not reset to "Search Criteria Page". Resetting happens only when you visit the page. This means, suppose, there is another JSR286 portlet or a JSF Portlet on that page and "Search JSF Portlet" shows "Search Results Page". If you are doing any action on the other portlet and after the page is rendered, "Search JSF Portlet" will continue to show "Search Results Page".

Wednesday Nov 04, 2009

JSR 286: A Comprehensive article

I have been blogging about the features of JSR 286(Java Portlet Specification 2.0) from the time the expert group(of which i was one of the members representing Sun Microsystems), started publishing the draft specification. Everytime one asks me how a feature in JSR 286 works, i have to point him to one of my blogs. A comprehensive article on all features of JSR 286 was missing.

I have written a comprehensive article that includes all features of JSR 286 with examples. This also includes less talked about ones like wild card in eventing, alias support, Portlet URL listeners, etc..If you see that any feature is missing or if there any corrections to be done, let me know, i will incorporate them. Thanks.

The comprehensive article on JSR 286 is at https://portlet-container.dev.java.net/docs/jsr286.html

Monday Jun 29, 2009

ICE Faces Portlet in OpenPortal Portlet Container and Web Space

There has been discussion in ICEFaces forum and at http://portlet-container.dev.java.net mailing list regarding deploying ICEFaces Portlet in OpenPortal Portlet Container. The issue is that after deploying the ICEFaces portlet(that uses AJAX push capability), when you access the Portlet, you get an ICEfaces popup window in the browser with the message "user session expired" and a "Reload" button. Thanks to the ICEFaces team, they found the issue and mentioned that it was related to the cookies for JSESSIONID and paths. The problem is that the portlet container is running in its own context(/portletdriver) separate from the ICE Faces portlet's context for Ajax requests. And the solution suggested was to deploy the portletdriver at root context.

I found another solution which works if you don't want to deploy portletdriver to the root context. This also works for the case where you deploy Web Space server to a non-root context.

This involves adding the following to the sun-web.xml

   <session-config>
        <cookie-properties>
            <property name="cookiePath" value="/" />
        </cookie-properties>
    </session-config>

After adding this entry you need to redeploy the portletdriver.war/webspace.war.

If you are using OpenPortal Portlet Container on Tomcat, you need to add emptySessionPath to the server.xml.

 <Connector port="8080" .... 
         emptySessionPath="true" /> 

Monday Mar 23, 2009

Changing log level in Portlet Container

The Portlet Container 2.x that is part of  Sun GlassFish Web Space Server , Liferay and OpenPortal Portlet Container uses JDK logging (JSR 47) for logging messages , exceptions etc. By default the log level in GlassFish is INFO. If you need to disable the portlet container logs or change the log level, how to do it?. Following are the steps..

  1. Login to GlassFish adminconsole(default: localhost:4848)
  2. Click on "Application Server" on the left side.Then click on Logging->Log levels as shown below




  3. Then scroll down and click on "Add Property" and enter the "debug.com.portal.portletcontainer" in Name field and any valid JDK Log level(eg: INFO or WARNING or SEVERE etc..) in Value field as shown below.




  4. Click on "Save". This should take effect immediately, no restart is required.

        
    

Tuesday Jul 22, 2008

Article in TheServerSide.com uses OpenPortal Portlet Container

Recently one of colleagues came across an article the TheServerSide.com that explains the "Action Scoped Request attributes" container runtime option. The article uses OpenPortal Portlet Container to explain the feature.

My colleague in his blog talks about this and also why he likes OpenPortal Portlet Container.

Thursday Jul 03, 2008

JSR286: Wildcards in Eventing

The eventing feature in JSR 286 supports wildcard. In order to use wildcard, the portlet must organize the local part of the event names in the event-definition element in a hierarchical manner using the dot(‘.’) as separator. for example: "foo.event.one". 

Wildcards should only be used in the supported-processing-event or supported-publishing-event elements.

If the wildcard string should match a part of a hierarchy two dots are required at the end of the wildcard string: one to denote the hierarchy and one for the wildcard, for example: "foo..".

The event name must be part of the hierarchy, not a substring. For example "foo." matches "foo.bar", but it does not match "football"


Consider the following example:

<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd
             http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
             id="myPortletApp" version="2.0">
   <portlet>
      ...
      <portlet-name>Portlet1</portlet-name>
      ...
      <supported-publishing-event>
         <qname xmlns:x=”http:example.com/events”>x:foo.event.</qname>
      </supported-publishing-event>
      ...
   </portlet>
   <portlet>
      ...
      <portlet-name>Portlet2</portlet-name>
      ...
      <supported-processing-event>
         <qname xmlns:x=”http:example.com/events”>x:foo.event.</qname>
      </supported-processing-event>
      ...
   </portlet>
   <portlet>
      ...
      <portlet-name>Portlet3</portlet-name>
      ...
      <supported-processing-event>
         <qname xmlns:x=”http:example.com/events”>x:foo..</qname>
      </supported-processing-event>
      ...
   </portlet>
   <portlet>
      ...
      <portlet-name>Portlet4</portlet-name>
      ...
      <supported-processing-event>
         <qname xmlns:x=”http:example.com/events”>x:foo.e.</qname>
      </supported-processing-event>
      ...
   </portlet>

   <event-definition>
      <qname xmlns:x=”http:example.com/events”>x:foo.event.one</qname>
      <value-type>com.example.Address</value-type>
   </event-definition>
   <event-definition>
      <qname xmlns:x=”http:example.com/events”>x:foo.event.two</qname>
      <value-type>com.example.Address</value-type>
   </event-definition>
   <event-definition>
      <qname xmlns:x=”http:example.com/events”>x:foo.bar.event</qname>
      <value-type>com.example.Address</value-type>
   </event-definition>
</portlet-app>

  • Portlet1 can publish the events x:foo.event.one and x:foo.event.two as the event definitions "x:foo.event.one" and "x:foo.event.two" begins with "x:foo.event."
  • Portlet2 can process the events x:foo.event.one and x:foo.event.two as the event definitions "x:foo.event.one" and "x:foo.event.two" begins with "x:foo.event."
  • Portlet3 can process the events x:foo.event.one, x:foo.event.two and x:foo.bar.event as the event definitions "x:foo.event.one", "x:foo.event.two" and "x:foo.bar.event" begins with the hierarchy "x:foo."
  • Portlet4 cannot process any event as there is no event that begins with the hierarchy x:foo.e. (Note: e. and event. are two different hierarchies, i.e, e. does not mean starting with e)

The recently released OpenPortal Portlet Container 2.0 supports wildcard in eventing.

Thursday Mar 20, 2008

JSR286: defineObjects Tag (variables available in the JSP)

I have got lot of queries about the variables to be used in JSP page when included from within a Portlet. Also few problems were reported that the new variables introduced in JSR 286 are not working as expected. Let me explain both.

JSR 168 (Portlet 1.0)

In JSR 168 only three variables are defined:
  • RenderRequest renderRequest
  • RenderResponse renderResponse
  • PortletConfig portletConfig
In order to use them you must refer to the taglib uri and use defineObject Tag in the JSP page as follows

<%@ taglib uri=”http://java.sun.com/portlet” prefix=”portlet”%>

<portlet:defineObjects/>


JSR 268 (Portlet 2.0)


In JSR 286 following variables are defined:
  • RenderRequest renderRequest and RenderResponse renderResponse (if the JSP is included from render method)
  • ResourceRequest resourceRequest and ResourceResponse resourceResponse (if the JSP is included from serveResource method)
  • ActionRequest actionRequest and ActionResponse actionResponse (if the JSP is included from processAction method)
  • EventRequest eventRequest and EventResponse eventResponse (if the JSP is included from processEvent method)
  • PortletConfig portletConfig
  • PortletSession portletSession (returns an existing session or null if no session exists)
  • Map<String, Object> portletSessionScope (provides access to the portletSession attributes)
  • PortletPreferences portletPreferences (provides access to the portlet preferences)
  • Map<String, String[]> portletPreferencesValues (provides access to the portlet preferences as a Map)

In order to use the variables you must refer to a different taglib uri and use defineObject Tag in the JSP page as follows


<%@ taglib uri=”http://java.sun.com/portlet_2_0” prefix=”portlet”%>

<portlet:defineObjects/>

 

Thursday Mar 13, 2008

OpenPortal Portlet Container 2.0 RC1 released

The first Release Candidate of OpenPortal Portlet Container 2.0 (implementation of JSR 286 specification) is now available for download.

Samples are available to test the new features.

It is recommended that you uninstall Portlet Container 2.0 Beta2 before installing RC1

This release has few additional features/enhancements and fixes since the beta2..

  • Support for Container Events
    • Currently login/logout event is supported, more will be added later. Check Issue 66 for the sample
  • Support for Roles
  • JAXB for marshalling/unmarshalling event payload
  • Fix that enables running Visual Web Components as portlets
  • Few enhancements to support WSRP 2.0

The Issue List contains the details of the additional features/enhancements and fixes.

Netbeans Portlet Pack 2.0 Beta3 is available that helps developers to develop, deploy and test portlets on the Portlet Container 2.0 RC1.

If you have questions on how to use the OpenPortal Portlet Container and other comments/suggestions/requests, we urge you to join the users@portlet-container.dev.java.net alias.

Please report any issues that you encounter while trying OpenPortal Portlet Container RC1 to issues@portlet-container.dev.java.net.

Friday Mar 07, 2008

JSR286 : The Eventing feature (updated)

When the Java Portlet Specification(JSR 286) early draft was released last year, i had written a blog on the Eventing. Recently the proposed final draft was released, it has some changes in the eventing feature. In this blog i will explain the feature with an example.

To create portlets that use the eventing feature, follow these steps(snippets from EventingMap sample application):

1.Declare the events in the portlet.xml

    1.1 Set the event definition at the portlet application level. This specifies the event name and the object type.
        Note: The object must be serializable and must be instrumented with valid JAXB annotation

   <portlet-app xmlns="http://java.sun.com/xml/ns/portlet/
portlet-app_2_0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/
portlet-app_2_0.xsd
http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
id="myPortletApp" version="2.0">
<portlet>
. . .
. . .
</portlet>

<event-definition>
<qname xmlns:x="http:sun.com/mapevents">x:Continent</qname>
<value-type>com.sun.portal.portlet.mapevent.Continent</value-type>
</event-definition>

</portlet-app>


@XmlRootElement
public class Continent implements Serializable {
public Continent() {
}
private String name;
private String description;

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}

public String getDescription() {
return description;
}

public void setDescription(String description)
this.description = description;
}
}

  1.2 In the portlet section, specify the event name defined above for those portlets that want to publish this event.

        <portlet>
<description>ContinentPortlet</description>
<portlet-name>ContinentPortlet</portlet-name>
            .................
<supported-publishing-event>
<qname xmlns:x="http:sun.com/events">x:Continent</qname>
</supported-publishing-event>

        </portlet>


    1.3 In the portlet section, specify the event name defined above for those portlets that want to process this event.

    <portlet> 
<description>ContinentMapPortlet</description>
<portlet-name>ContinentMapPortlet</portlet-name>
. . .
<supported-processing-event>
<qname xmlns:x="http:sun.com/events">x:Continent</qname>
</supported-processing-event>

</portlet>
  <portlet>
<description>ContinentInfoPortlet</description>
<portlet-name>ContinentInfoPortlet</portlet-name>
. . .
<supported-processing-event>
<qname xmlns:x="http:sun.com/events">x:Continent</qname>
</supported-processing-event>

</portlet>
. . .
</portlet-app>

    
2. Issue an event in the portlet that was specified as supported-publishing-event in the portlet.

public class ContinentPortlet extends GenericPortlet {

public void processAction(ActionRequest request, ActionResponse response)
throws PortletException,IOException {

QName qname = new QName("http:sun.com/mapevents" , "Continent")
String value = request.getParameter("continent");
Continent continent = new Continent();
continent.setName(value);

ResourceBundle rb = getPortletConfig().getResourceBundle(request.getLocale());
continent.setDescription(rb.getString(value));
response.setEvent(qname, continent);
}
. . .
}

3. Process the event in the portlet that has specified as supported-processing-event in the portlet

public class ContinentInfoPortlet extends GenericPortlet {

public void processEvent(EventRequest request, EventResponse response) {

Event event = request.getEvent();
if(event.getName().equals("Continent")){
Continent payload = (Continent)event.getValue();
response.setRenderParameter("continentDescription",
payload.getDescription());
}

}

. . .

}


public class ContinentMapPortlet extends GenericPortlet {
public void processEvent(EventRequest request, EventResponse response) {

Event event = request.getEvent();
if(event.getName().equals("Continent")){
Continent payload = (Continent)event.getValue();
response.setRenderParameter("continentName", payload.getName());
}

}
. . .
}

You can download the binary file EventingMap.war to deploy and run the sample application in OpenPortal Portlet Container 2.0 Beta2(or latest). You can also get the source for the sample.

The figure shows the World Map, Continent Information, and Continent Map Portlets that participate in the event. Clicking on any continent in the World Map triggers an event. This event is processed by the Continent Information and Continent Map Portlets to show the relevant information.


Monday Feb 11, 2008

JSR286 : Public Render Parameter feature (updated)

When the Java Portlet Specification(JSR 286) early draft was released last year, i had written a blog on Public Render Parameter feature. Recently the proposed final draft was released, it has some changes in public render parameter feature. In this blog i will explain the feature with an example.

In JSR 168, the render parameters set in processAction is only available in the render of the same portlet.

With the Public Render Parameters feature, the render parameters set in the processAction of one portlet will be available in render of other portlets also. Using public render parameters instead of events avoids the additional process event call.

In order to allow coordination of render parameters with other portlets, within the same portlet application or across portlet applications, the portlet can declare public render parameters in its deployment descriptor using the public-render-parameter element in the portlet application section. Public render parameters can be viewed and changed by other portlets or components.

In the portlet section each portlet can specify the public render parameters it would like to share via the supported-public-render-parameter element. The supported-public-render-parameter element must reference the identifier of a public render parameter defined in the portlet application section in a public-render-parameter element.

In the code, the portlets should use the defined public render parameter identifier to access the public render parameter(new addition in the proposed final draft).

To create portlets that use the public render parameters, follow these steps(snippets from WeatherMap sample application):

1. Declare the render parameters to be shared in the portlet.xml file by setting the public render parameters at the portlet application level.

      <portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"             
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"             
                   xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd
                                       http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
                   id="myPortletApp" version="2.0">
        <portlet>
         . . .
        </portlet>
                      
        <public-render-parameter>
          <identifier>zip-id</identifier>
          <qname xmlns:x="http://sun.com/params">x:zip</qname>
        </public-render-parameter>

      </portlet-app>

       
2. Specify the render parameter that the portlet would like to share in the portlet section.

      <portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"             
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"             
                   xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd
                                       http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
                   id="myPortletApp" version="2.0">
      <portlet>
         <description>WeatherPortlet</description>
         <portlet-name>WeatherPortlet</portlet-name>
         <display-name>WeatherPortlet</display-name>
         <portlet-class>com.sun.portal.portlet.WeatherPortlet</portlet-class>
         ......               
         <supported-public-render-parameter>zip-id</supported-public-
         render-parameter>
      </portlet>

      <portlet>
         <description>MapPortlet</description>
         <portlet-name>MapPortlet</portlet-name>
         <display-name>MapPortlet</display-name>
         <portlet-class>com.sun.portal.portlet.MapPortlet</portlet-class>
          . . .
         <supported-public-render-parameter>zip-id</supported-public-
         render-parameter>
      </portlet>
          .  . .
      </portlet-app>

       
3. Set the render parameter in the processAction() method:

      public class WeatherPortlet extends GenericPortlet {
           . . .
         public void processAction(ActionRequest req, ActionResponse res)
         throws IOException, PortletException {
          . . .
                 res.setRenderParameter("zip-id", zip);
           }
           . . .
      }

You can download the binary WeatherMap.war file to deploy and run the sample application in OpenPortal Portlet Container 2.0 Beta2 (or latest). You can also get the source for the sample. If you are behind a firewall you need need to set the proxy in the webcontainer configuration.

The figure shows the Weather and Map portlets. The Weather portlet sets the zip-id which is declared as a Public Render Parameter. This parameter is supported by both Weather and Map portlets. Any change in the value of zip by Weather portlet is reflected during the render phase of both weather and map portlets.

Weather Map Sample 

Tuesday Jan 08, 2008

Portlet Container 2.0 Beta2 released

The OpenPortal Portlet Container 2.0 Beta2 has been released. This release is based on JSR 286 proposed final draft. This release contains following features and enhancements..

  • Eventing
  • Public Render Parameters
  • Resource Serving
  • Portlet Filters
  • Validation based caching
  • Request Dispatcher Include from all lifecycle
  • Request Dispatcher Forward from all lifecycle
  • Container Runtime Options that includes escapeXml and actionScopedRequestAttributes
  • Taglibrary enhancements

Netbeans Portlet Pack 2.0 Beta2 is available that helps developers to develop, deploy and test portlets on the Portlet Container 2.0 Beta2.

About

Deepak Gothe

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today