In the previous Developing Portlets Using JSP & Servlet we clarified you how can we use a Portlets, JSPs & Servlets for creating an MVC architectual application that’s easy to maintain, easy to debug and easy to develop.

But why we would waste a lot of time in developing such that orchestration while others were already did. JSF framework are MVC compliant framework, as its components contained the concept of Separation of concern (SoC).

Facelets technology are used for handling the view purposes, its backing bean act as controllers and you can use its Expression Language for glue your views with the proposed models.

It’s elegant framework as you can use it within your Portlets, that will make them JSF-based Portlets. For this purpose, Java Community (JC) has proposed two different JSR (Java Specification Request) to simplify integrating your Portals with the well-know JSF framework.

JSR-301 is a Portlet container specification that defines the required behavior of a JSR-168,286 (Portlet Specification) that proxies for JSF artifacts. Meanwhile, JSR-329 is for Portlet container 2.0 bridge for JavaServer Faces (JSF) 1.2 Specification that defines the required behavior for allowing the JSF Application/View to be accessed as a Java Portlet.

Until writing these lines, no specification has been released for JavaServer Faces 2.0, though the implementation is already provided. This tutorial will provide you detailed information that help you getting all these technologies integrated each together as they work efficiently.

  • Any Portal (Portlet container 2.0 compliance) Like Apache Pluto.
  • JSF 2.0 (Either by using MyFaces 2.0 or by using Reference Implementation JSF Mojarra 2.0).
  • Any Portlet Bridge that’s compliant with JSR-329 like MyFaces 2.0 Portlet Bridge.

Employee registration operation is the process for which the integration will be achieved, as no need for using of Standard Java Portlet, Java Server Pages and Servlet for doing so.

Database Design & Required Model

For explaining purposes, it’s good for you to know what’s the form of the database table that we would use for retaining the registered employees.

Employee-Table (5)


Employee entity (Model) that would be created according for employee Table figured above will be:

Design View

The design view for the operation of employee registration is just as JSF framework has done, the process of bridging has eliminated the need of walking through Portlet container accompanies.

Employee-Table (5)

The figured design depicts you for how the flow of execution have to proceed, it’s just like any JSF application you may be made in the past.

Register Employee XHTML

JSF 2.0 has used a Facelets as view technology instead of JSP that’s supported by JSF 1.x. Registration employee page would look like below:


Here’s detailed explanation for the code listed above:

  • Registration page has used the XHML format. Facelets has supported the XHML as a format of its view.
  • The user need to fill in all required information fields like identity and salary, in case you’ve missed them out, an error message would be flagged. These error messages are shown by the JSF framework itself as we’ve used a <f:validateRegex/> and required attributes.
  • In case you’ve entered a Not Number value within identity or salary fields, a JSF error message would be displayed tell you that you’re entering an invalid value.
  • All fields are associated with their respective attributes against employee property that’s already defined in the RegisterEmployeeManagedBean. As so, no submitted values are extracted from the request object.

Register Employee Managed Bean

As JSF promised, everything will get retained into your bean, no need for orchestrating a lot of components that you’ve used before for extracting the user submitted parameters as no need for handling much issues you may do in case you’ve decided to not use a JSF framework like messages, locales and so on.

Here’s detailed explanation for the bean code figured out:

  • A plain old Java object (POJO) employee is used for binding purpose. In JSF, each component may be associated with a value provided by the Managed Bean. Once the form has been submitted, JSF framework has been started and the submitted values are transferred magically into the binded bean.
  • As we’ve JSF 2.0, no need for faces configuration file (faces-config.xml), and so, we used the newly added annotations for declaring the managed bean and its scope.
  • Remember as no JSR proposed for JSF 2.0, but it’s already implemented and you may get used in a lot of Portlet container that’s supported JSR-286.
  • You may notice using of EmployeeDAO and ConnectionUtility, if you remember what we have discussed at the Developing Portlets Using JSP & Servlet where in, your good design lead you for easy-to-maintain code, easy-to-debug and easy-to-develop (i.e. Separation of concern). Look at now, you have the ability to re-use the code you made. Really !! nothing touched with these two utilities.
  • All of these classes that are relevant for the database communication have been got isolated to be used later on by any presentation layer. So, you either use the JSF, default JSP/Servlet, normal Java Desktop application or you may wrap them up to be SOAP-based service or Restful-based service.
  • The user will get a confirmation messages either the registration process has been finished successfully or it’s being failed.
  • In case the registration process has failed, the confirmation message would show you the main cause for this failure.

JSF-Portlet Bridge Dependencies

As we’ve mentioned before in that the Portlet Bridge is just a specification, so a lot of vendors have implemented it. We will use the MyFaces 3.0.0-alpha version that’s provided for Portlet Container 2.0. Two dependencies listed below must be added into your Maven build file to get Portlet Bridge implementation involved and used.


JSF Implementation & Deployment Descriptor

JSF is a standard specification, that’s mean different vendors have already provided their own implementation. However, this part of tutorial is very important one as we would show you how can use two different implementations for getting JSF implementation used and what’s the impact of that usage on the deployment descriptor file.

Let’s firstly choose the most standard JSF implementation, it’s for sure a JSF Mojarra 2.0. You must add these below dependencies into you own maven for make use of JSF Mojarra.

JSF - Reference Implementation - Mojaraa Dependencies

And so, your web.xml file should be like this:


But let’s see now what are these dependencies required for making MyFaces 2.0 get used instead of Reference Implementation JSF Mojarra 2.0.

JSF - MyFaces Dependencies

And so, you must have the same entries listed above in the web.xml but with major change, in that the listener mentioned must be removed.


Full Maven Build File

Find below full maven build file that will be used for implementing a JSF/Mojarra Portlet.


EmployeeDAO & ConnectionUtility

Now, it’s time to make a fast look at the EmployeeDAO and ConnectionUtility classes. These classes are used to handle all of these issues that are relevant for Database connectivity.

Register Employee Demo

The demonstration starts by deploying your developed WAR into your Apache Pluto Portlet container 2.0. Log in into your Apache Pluto and navigating into JournalDev page that’s already implemented in the previous introduced tutorials.


Let’s see how JSF served you in case you’ve entered an invalid values, for that just put a character values inside both of id and salary fields.


But what’s happened if we’ve tried to register already registered employees.


What’s happened if we register a new employee.



This tutorial is a unique one as it’s summarized the all required information for getting used a JSF-based application onto Portlet container. The all required configuration, dependencies, accompanies classes and much more, they are listed completely here. Contribute us by commenting below and find downloaded source code.

By admin

Leave a Reply

%d bloggers like this: