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.

Wednesday Jun 09, 2010

JSF Portlet File Upload

[Links Updated]

Recently a project student had a requirement to use file upload functionality in JSF Portlet. Since Mojarra's JSF Implementation does not provide fileupload component, he wanted to use the fileupload component provided by MyFaces Tomahawk component library. He used the example from this blog and portletized it. But it didn't work with either OpenPortal JSF Portlet Bridge or  Apache MyFaces JSR329 Portlet Bridge. I found another blog post that talks about extending OpenPortal JSF Portlet Bridge inorder to provide support for fileupload. It worked, but i wanted a generic solution that works with both OpenPortal JSF Portlet Bridge and Apache MyFaces JSR329 Portlet Bridge or any other JSF Portlet Bridge. So i used the Portlet Filter approach based on that blog. Ofcourse this solution will work only on portals that support JSR286.

Following are the steps to add fileupload functionality in your jsf portlet

1. Add the following JARs to the WEB-INF/lib of the jsf portlet webapp. The version numbers doesn't matter as long as you get the newest.

2. Add the following portlet filter entry in the portlet.xml

<portlet-app ..... version='2.0'>
    <portlet>
        <portlet-name>name_of_the_portlet</portlet-name>
                ........
    </portlet>
    <filter>
        <filter-name>PortletFileUploadFilter</filter-name>
        <filter-class>com.sun.portlet.PortletFileUploadFilter</filter-class>
        <lifecycle>ACTION_PHASE</lifecycle>
    </filter>
    <filter-mapping>
        <filter-name>PortletFileUploadFilter</filter-name>
        <portlet-name>name_of_the_portlet</portlet-name>
    </filter-mapping>
</portlet-app>


3. Define the fileupload component in the JSF page (you will use the name to get FileItem from the request)

<input type="file" name="name_of_the_component" />

4. After you submit the JSF page, you can obtain the org.apache.commons.fileupload.FileItem for the input file component from the PortletRequest as follows. Once you have access to FileItem you can get the name, the I/O stream of the uploaded file.

FacesContext facesContext = FacesContext.getCurrentInstance();
PortletRequest portletRequest = (PortletRequest) facesContext.getExternalContext().getRequest();
FileItem fileItem = (FileItem)portletRequest.getAttribute("name_of_the_component");

See the example jsf fileupload portlet that uses this functionality.

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

Tuesday Aug 25, 2009

Coordination between portlets across pages

There has been lot of queries asking me how to send/receive events with portlets that are not on same page. So I thought let me blog about this.

In order to provide coordination between portlets the Java Portlet Specification, JSR 286 introduces Eventing and Public Render Parameters

Eventing:

   By default portlets can send and receive events with other portlets that are on the same page. This can be changed to enable portlets to send and receive events from other portlets that are on different pages. This can be done by adding the following property in portal-ext.properties in Web Space server and Liferay Portal 5.2.x.

portlet.event.distribution=ALL_PORTLETS


Public Render Parameters:

   By default portlets can share render states with other portlets that are on the same page. This can be changed to enable portlets to share render states with other portlets that are on different pages. This can be done by adding the following property in portal-ext.properties in Web Space server and Liferay Portal 5.2.x.

portlet.public.render.parameter.distribution=ALL_PORTLETS


Preventing infinite loops in Eventing:

    The following property is used to specify the maximum number of events that can be generated from portlets to prevent infinite loops. If a portlet sends an event to other portlets, it is considered as one event generation. If the other portlets send events, that is considered as two event generations and so on. The default value is 3.

portlet.event.max.generation=3

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" /> 

Friday Feb 20, 2009

XMLPortletRequest in Portlet Container 2.1

XMLPortletRequest is a wrapper over XMLHttpRequest and shares the same syntax and semantics with XMLHttpRequest.

If a portlet wants to update its UI asynchronously through resource URL, it would simply use XMLPortletRequest instead of the XMLHttpRequest.


Here is an example on how to use XMLPortletRequest.

<script type="text/javascript" 
        src="<%=renderRequest.getContextPath()%>/js/XMLPortletRequest.js">
</script>
<script>
    var portletRequest = new XMLPortletRequest("<portlet:namespace/>");
    portletRequest.onreadystatechange = function() {.....}
    portletRequest.open("POST", "<portlet:resourceURL escapeXml='false' />");
    portletReq.send("foo=" + bar);
</script>

Check the XPRInvoiceAjaxPortlet sample(sources and binary) that showcases the usage of XMLPortletRequest. Using XMLPortletRequest drastically reduces the amount of code. Compare the view jsp page of InvoiceAjaxPortlet that does not use XMLPortletRequest with view jsp page of XPRInvoiceAjaxPortlet that uses XMLPortletRequest.

This feature has been added in Portlet Container 2.1. This is available in OpenPortal Portlet Container 2.1, Sun GlassFish Web Space Server 10.0 and Liferay version 5.2 and higher.

OpenPortal Portlet Container 2.1 released

The OpenPortal Portlet Container 2.1 has been released.

The Portlet Container 2.1 is also part of following releases


Why the version is called 2.1 and not 2.0 update 2 ?

Because, this release has lot of changes and is a major release. Following is brief list of changes  that went into this release

  • Major enhancements to support WSRP 2.0 FCS, GlassFish Web Space Server and Liferay version 5.2.
  • New features like XMLPortletRequest.
  • Jar name changes to support the deployment of OpenPortal Portlet Container and GlassFish Web Space Server on the same domain of GlassFish.
  • The third party jars used by the driver have been updated(like commons-fileupload, JSTL and Standard jars)

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.

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.

Friday Feb 13, 2009

Portlet Container in Sun GlassFish Web Space Server

Sun GlassFish Web Space Server 10.0 has been released. This release uses Portlet Container 2.1

The Portlet Container 2.1 is a fully compliant implementation of the Portlet 2.0 (JSR286) specification. And it also implements many of the optional features like

You get all these features in Sun GlassFish Web Space Server 10.0 which is based on Liferay Portal 5.2.  Apart from that we have added XMLPortletRequest. More about XMLPortletRequest in my next blog.

Friday Nov 07, 2008

GlassFish v3 Prelude and Portlet Container 2.0_01

The OpenPortal Portlet Container 2.0 Update 1 runs on GlassFish v3 Prelude

Set ANT_HOME and use CLI to install as follows (there is an issue with GUI install)

java -jar portlet-container-configurator.jar glassfishv3-prelude\\glassfish glassfishv3-prelude\\glassfish\\domains\\domain1

Note: the glassfish home is glassfishv3-prelude\\glassfish

Please report any issues that you encounter to users@portlet-container.dev.java.net.


Friday Oct 31, 2008

OpenPortal Portlet Container 2.0_01 released

The OpenPortal Portlet Container 2.0 Update 1(2.0_01) has been released.

The OpenPortal Portlet Container 2.0_01 is also part of Java Application Platform SDK Update 6.

This release has some important fixes and enhancements to support WSRP Beta and Liferay integration. The changelog contains issues resolved. 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 Portlet Container 2.0_01.

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.

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.



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.

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