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'>

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


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

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

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

    <h:form id="helloForm">
    <h:inputText id="userNo" value="#{UserNumberBean.userNumber}"

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..
        <qname xmlns:x="">x:userNumber</qname>

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 20, 2007

JSF Portlet Bridge in Maven Repository

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

Put this in your pom.xml

Under <repositories>

            <name> Repository for Maven</name>

Under <dependencies>


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.



Deepak Gothe


« June 2016