Sunday Oct 19, 2008

JSF portlet and Public Render Parameters

In this blog i will talk about the support for public render parameter (new feature that was added in Portlet 2.0 specification) in the JSF Portlet Bridge.

In JSFPortletBridge version 1.2.3 an enhancement was added to keep track of request scoped information. Check the issue 30 for more details. This feature can be used to support the sharing of render parameters among jsf portlets. I will explain how to do it. The example war and source is referenced at the end.

1. First you need to set the following initialization parameter in the portlet.xml for the portlet that wants to share the render parameter
       <init-param>
            <name>com.sun.faces.portlet.SAVE_REQUEST_SCOPE</name>
            <value>true</value>
        </init-param>      

This causes the form parameters to be set as render parameters. As a result all form parameters are available in the render of the portlet.

2. Now identify the parameter to be shared and specify it in the portlet.xml. Since JSF generates the name, you need to specify the generated name in the portlet.xml..For example consider the following snippet

<f:view>
    <h:form id="helloForm">
        .............
    <h:inputText id="userNo" value="#{UserNumberBean.userNumber}"
             validator="#{UserNumberBean.validate}"/>
    .................
    </h:form>
</f:view>

If you want to share the inputText "userNo", then specify the parameter "helloForm:userNo" as supported-public-render-parameter.

If you notice i have dropped the tag <p:portletPage> . This tag causes the portlet namespace to be prepended to the parameter name. The parameter name will be "portletnamespace:helloForm:userNo". The namespace that is generated by the portlet container will be different in each portal. So i have removed it.

The parameter can be specified in the portlet.xml as follows..
<portlet-app>
    <portlet>
    ...........
        <supported-public-render-parameter>helloForm:userNo</supported-public-render-parameter>
    </portlet>
    <public-render-parameter>
        <identifier>helloForm:userNo</identifier>
        <qname xmlns:x="http://www.sun.com/params">x:userNumber</qname>
    </public-render-parameter>
</portlet-app>


3. If another JSF Portlet also specifies the same parameter as supported-public-render-parameter, then it can access the parameter as

    FacesContext context = FacesContext.getCurrentInstance();
    PortletRequest request = (PortletRequest)context.getExternalContext().getRequest();
    return request.getParameter("helloForm:userNo");

This will return the value entered in the first JSF Portlet.

Deploy the guessnumbersharedportlet.war on OpenPortal Portlet Container 2.0 and see the public render parameter at work. You can check the sources to see how this is done. The sample will work on Project WebSynergy and Liferay Portal also.



Friday Jul 25, 2008

OpenPortal Portlet Container in Liferay

Recently OpenPortal Portlet Container was fully integrated in Liferay Portal.

The OpenPortal Portlet Container is a fully compliant implementation of the Portlet 2.0 (JSR286) specification. And it also implements many of the optional features like expiration and validation caching, support for alias in eventing and public render parameters, support for wild card in eventing. It is already a part of Project WebSynergy and  Sun Java System Portal Server 7.2.

The WSRP 2.0 implementation provided by the WSRP Project works seamlessly with our Portlet Container. Thus the embedding of the Portlet Container in Liferay Portal  ensures that the WSRP 2.0 implementation can also be integrated.

Similarly you can embed this Portlet Container in any Portal based on the steps documented in this article.

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.

Tuesday Jun 24, 2008

Open Portal Portlet Container 2.0 released

OpenPortal Portlet Container 2.0 has been released.

The release is a fully compliant implementation of the Portlet 2.0 (JSR286) specification, which was released last week. It is recommended that you uninstall previous versions before installing this release.

The SDN article describes the new features along with samples.

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

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.

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.

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

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