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.

Thursday Sep 20, 2007

Portlet Container 2.0 beta is now available in the new Java Application Platform SDK Update 3 beta

The Java Portlet Specification, 2.0 (JSR 286) adds new features like events, public render parameters, resource serving, and portlet filtering.

Portlet Container 2.0 Beta that is part Java Application Platform SDK Update 3 beta provides a preview of these new features as defined in the JSR 286 Public Draft 1.

Link to resources and docs for Portlet Container 2.0 Beta Component

The Java Application Platform SDK Update 3 Beta also includes Web Services for Remote Portlets (WSRP) 1.0 Beta.

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

 

Friday Aug 24, 2007

OpenPortal Portlet Container 1.0 Update 1 has been released

We've released the OpenPortal Portlet Container 1.0 Update 1 (1.0_01).

The changelog contains issues resolved.

If you find any issues or have any feedback, etc., please let us know!

Thursday Aug 16, 2007

JSR 286 : Public Render Parameters feature

I had written this blog when the early draft of JSR 286 was released. Recently the proposed final draft was released, it has some changes in public render parameter feature. I have written a new blog to explain this feature with an example. 

In order to provide coordination between portlets the Java Portlet Specification, JSR 286 introduces the following mechanisms

  • Eventing: portlet events that a portlet can receive and send
  • Public Render Parameters: render state that can be shared between portlets

In my previous blog, i explained Eventing feature and in this blog will explain the Public Render Parameter feature.

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.

How it works..
Consider the following example..

Declare the render parameters to be shared in the portlet.xml
    1. Set the public render parameters at the portlet application level.
    <portlet-app .....>
        <public-render-parameter>
            <identifier>id1</identifier>
            <qname xmlns:x="http://sun.com/params">x:param1</qname>
        </public-render-parameter>
        <public-render-parameter>
            <identifier>id2</identifier>
            <qname xmlns:x="http://sun.com/params">x:param2</qname>
        </public-render-parameter>

    2. Specify the render parameter the portlet would like to share in the portlet section.
    <portlet>
        ...............
            <portlet-name>PortletA</portlet-name>
        ...............
             <supported-public-render-parameter>id1</supported-public-render-parameter>
             <supported-public-render-parameter>id2</supported-public-render-parameter>
        ...............
    <portlet>
    <portlet>
        ...............
            <portlet-name>PortletB</portlet-name>
        ...............
             <supported-public-render-parameter>id1</supported-public-render-parameter>
        ...............
    <portlet>
    <portlet>
        ...............
            <portlet-name>PortletC</portlet-name>
        ...............
             <supported-public-render-parameter>id2</supported-public-render-parameter>
        ...............
    <portlet>


   
1. If portletA sets the render parameter param1, portletB receives it but not portletC
2. If portletA sets the render parameter param2, portletC receives it but not portletB
3. If portletB sets the render parameter param1, portletA receives it but not portletC
4. If portletC sets the render parameter param2, portletA receives it but not portletB

You can checkout the sources from OpenPortal Portlet Container that has the implementation of the public render parameter feature. Write portlets that uses this feature and try it.

Thursday Aug 09, 2007

JSR 286 : The Eventing feature

In order to provide coordination between portlets the Java Portlet Specification, JSR 286 introduces the  following mechanisms

  • Eventing: portlet events that a portlet can receive and send
  • Public Render Parameters: render state that can be shared between portlets

In this blog, i will explain the Eventing feature and in a later blog i will explain the Public Render Parameter feature.

Eventing can be described as a loosely coupled, brokered means of communication between portlets. It is intended to allow portlets to react on actions or state changes not directly related to an interaction of the user with the portlet.
Events are a lifecycle operation that occurs before the rendering phase.


Now let us get into the details of writing portlets that use this feature

The portlet can declare the events in its deployment descriptor using the event-definition element in the portlet application section. In the portlet section each portlet can specify the events it would like to publish via the supported-publishing-event element and the events it would like to process via the supported-processing-event element. The supported-publishing-event and supported-processing-event element must reference the event name defined in the portlet application section in a event-definition element.

The portlet issues events via the setEvent method during the action processing. This will be processed by the portlet container after the action processing has finished.

In order to receive events the portlet must implement the javax.portlet.EventPortlet interface. The portlet container will call the processEvent method for each event targeted to the portlet with an EventRequest and EventResponse object.
The portlet can access the event that triggered the current process event call by using the EventRequest.getEvent method. This method returns an object of type Event encapsulating the current event name and value.

Event names are represented as QNames in order to make them uniquely identifiable. The event name can be either retrieved with the getQName method that returns the complete QName of the event, or with the getName method that only returns the local part of the event name. The value of the event must be based on the type defined in the deployment descriptor.

Following are the steps to write portlets that make use of eventing feature

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.
    <portlet-app .....>
        <event-definition>
        <qname xmlns:x="http:sun.com/events">
            x:Address.Create
        </qname>
        <value-type>com.test.Address</value-type>
        </event-definition>

    1.2 In the portlet section, specify the event name defined above for those portlets that want to publish this event.
        <portlet>
            .................
            <supported-publishing-event xmlns:x="http:sun.com/events">
                    x:Address.Create
            </supported-publishing-event>

    1.3 In the portlet section, specify the event name defined above for those portlets that want to process this event.
        <portlet>
            .................
           <supported-processing-event xmlns:x="http:sun.com/events">
                  x:Address.Create
           </supported-processing-event>

    
2.Issue an event in the portlet that was specified as supported-publishing-event in the portlet
    @XmlRootElement
    public class Address implements Serializable
    {
        private String street;
        private String city;
        public void setStreet(String s) {street = s;}
        public String getStreet() { return street;}
        public void setCity(String c) { city = c;}
        public String getCity() { return city;}
    }

    void processAction(ActionRequest request, ActionResponse response)
    {
        String myStreet = request.getParameter("street");
        String myCity = request.getParameter("city");
        Address sampleAddress = new Address();
        sampleAddress.setStreet(myStreet);
        sampleAddress.setCity(myCity);
        QName name = new QName("http:sun.com/events", "Address.Create");
        response.setEvent(name, sampleAddress);
    }     

3.Process the event in the portlet that has specified as supported-processing-event in the portlet
    void processEvent(EventRequest request, EventResponse response)
    {
        Event event = request.getEvent();
        if ( event.getName().equals("Address.Create") )
        {
            Address payload = (Address) event.getValue();
            .......
        }
    }

You can checkout the sources from OpenPortal Portlet Container that has the implementation of the eventing feature. Write a portlet that uses the eventing feature and try it.

 

Friday Jul 20, 2007

JSF Portlet Bridge in Maven Repository

We now have the JSF Portlet Bridge jars available on the java.net maven2 repository.

Put this in your pom.xml

Under <repositories>

        <repository>
            <id>maven2-repository.dev.java.net</id>
            <name>Java.net Repository for Maven</name>
            <url>https://maven2-repository.dev.java.net/nonav/repository</url>
        </repository>       

Under <dependencies>

      <dependency>
            <groupId>com.sun.faces.portlet</groupId>
            <artifactId>jsf-portlet</artifactId>
            <version>1.2.1</version>
            <scope>compile</scope>
        </dependency> 

The current versions are 1.2.1 and 1.1.5

Whenever the new version is available in JSF Portlet Bridge project site it will also be available via maven2 repository

Wednesday Jul 11, 2007

JSF Portlet Bridge 1.2.1 and 1.1.5 released

We've released the JSF Portlet Bridge 1.2.1 and 1.1.5.

The changelog contains issues resolved as well as any new features added.

If you find any issues or have any feedback for features, etc., please let us know!

To know more about JSF Portlet Bridge you can check the article JavaServer Faces Technology-Based Portlet Bridge

Tuesday Jul 03, 2007

New Contributor to JSF Portlet Bridge Project

The JSF Portlet Bridge Project is making steady progress. Late last year the project released JSF Portlet Bridge 1.2 which enables running JSF 1.2 applications as portlets in the OpenPortal Portlet Container. The project team is currently improving on that implementation.

   I would also like to welcome a new member to the project -- A. Alonso Dominguez, from Social Labs NetSolutions.  He is actively contributing for the implementation of JSR 301 in the project. JSR 301 is the Portlet Bridge Specification for JavaServer Faces Technology. It standardizes the behaviour of bridge implementations to ensure true interoperability for JSF artifacts. See the JSF Portlet Bridge Project for more details.

Thursday Jun 28, 2007

JSF Portlet Bridge Article

Marina and I just published an article on JSF Portlet Bridge titled:

Open-Source Portal Initiative at Sun, Part 5: JavaServer Faces Technology-Based Portlet Bridge.

The JSF Portlet Bridge Project is developing a JSF portlet integration library with which you can run and deploy JavaServer Faces technology-based applications as JSR 168-complaint portlets.

This article describes its design and binary, the procedure for modifying JSF applications to comply with JSR 168(illustrated by a sample application), and the tag library.

 

Friday Mar 23, 2007

Open Source Portlet Container Article

Following on the heels of part 1 and part 2 of the Portal Open Source series of articles, here is part 3

Open-Source Portal Initiative at Sun, Part 3: Portlet Container

This article describes the Enterprise-Class Portlet Container Open Source Project and Portlet Container 1.0, recently developed for that project. Also explained are the procedures for installing and deploying Portlet Container 1.0 so as to test portlets.
 

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