Architecture & DesignThe Two Faces of JSF on WLP

The Two Faces of JSF on WLP content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

IBM does it. Sun does it. Since 9.2, WebLogic does it. So, you can do it. Build JSF portlets.

With the yen for a bad song parody out of my system, JSF is seriously the up and coming technology in portals, even while JSR 301 is still in the early draft stage. In a recent bout of research on this topic, I was surprised to find that there is a JSF option for every J2EE-based portal I looked at. Even though I didn’t look at them all for this piece, I did look at a fair sampling of both COTS and FOSS portals. There are very few that have only JSF portlets, but the fact that some many include it as an option demonstrates the popularity of JSF among those that make the platform decisions.

Of course, there are two (or more) sides to the cutting-edge sword. Early adoption is just plain cool. Every passionate developer likes to build something in a way that few before them have. And, in today’s super-competitive market place, businesses that once waited for technologies to mature are now the front-runners in hopes of making up ground lost to the innovators of the last decade. JSF isn’t new; what is (fairly) new is using it in portals. Because there isn’t a fully defined standard for doing so yet, it’s anyone’s bet that if you build a JSF portlet using one set of tools, you may have to learn a whole new set in a year or two. Or, rewrite a good chunk of what you built when the standard is released.

The best advice I can give around early adoption is to minimize the use of proprietary libraries and not get too carried away innovating your own solutions to make a technology fit a solution. If a given technology isn’t quite ready for your project requirements, use another approach. One of the benefits of building JSF portlets in WLP is that the tools beyond the standard JSF libraries are open-source.

No Going Back for Wizard Lovers

To use JSF in WLP, you first must enable the JSF facet in your portal project. Once you have done this, any Page Flow portlets you create with the wizard dialogues will be JSF Page Flows. You can still build standard Beehive Page Flows, but you’ll need to start it manually.

If adding facets is new to you, it is very simple in Workshop and WorkSpace Studio. Right-click on the project and select properties. Select Project Facets and you will see a list of installed project facets and the Add/Remove button. Clicking the JSF checkbox and then Finish will install the defaults. If you are already well-versed in JSF or have specific version preferences, clicking “Next” will bring you to more detailed options.

Figure 1: Adding and Managing the JSF Project Facet

For new projects, you will see the same choice if you follow the “click Next” route in the project wizard rather than jumping straight to “Finish” after naming your project. If JSF is the only custom facet you need, there are fewer steps involved in adding the facet after you have created the project.

The Same, Only Different

With the JSF facet added, using the Page Flow wizard will generate the usual Page Flow controller and index.jsp. There are a couple of differences from the standard Beehive Page Flow files. The first difference is that the JSP will be a JSF JSP:

<%@ page language="java" contentType="text/html;charset=UTF-8"%>
<%@ taglib prefix="f" uri=""%>
<%@ taglib prefix="h" uri=""%>
         <f:verbatim><p>JavaServer Faces Page -

Note that the HTML head and body tags are included. Generally, these are undesirable in a portlet because they create an invalid DOM in a portal. However, some JSF libraries require this for compilation (another indication that the standards of JSF in portals are still incomplete), so you will need to make an individual call as to whether they should be removed for your particular portlet.

The other difference is that the forward defined for the JSF JSP has a .faces extension instead of a .jsp extension:

@Jpf.Controller(simpleActions =
   { @Jpf.SimpleAction(name = "begin", path = "index.faces") })

One new aspect when creating a Page Flow with the JSF facet is that a backing bean is generated for the JSF JSP. The backing bean created is a Beehive version:

package portlets.jsfPageFlowDemo;

import org.apache.beehive.netui.pageflow.FacesBackingBean;
import org.apache.beehive.netui.pageflow.annotations.Jpf;

 * This is the default Faces Backing file for a JSF Page.

public class index extends FacesBackingBean {
   private static final long serialVersionUID = 1L;

Creating a JSF Portlet

To create a portlet from your JSF Page Flow, the process is more similar to creating a JSP portlet than a standard Beehive Page Flow portlet. Where with Beehive Page Flows, the portlet Content Path is set to the Page Flow Controller, a JSF Page Flow starts from the JSF JSP. Note that, while in the portlet wizard, you will enter the path to the JSP, the resulting .portlet file contains the .faces extension in the path:


Because the path starts at the JSF JSP rather than a method on the Page Flow Controller, if you need to initialize values the first time the portlet is loaded, you need to do all of your initialization in the backing bean.

Because you do have a Page Flow Controller associated with the JSF JSP, you can call Page Flow actions using the NetUI tags. You can also use Beehive Form Beans. If you use Form Beans with JSF portlets, you may need to install a patch available from WebLogic support.

Coding the Old Fashioned Way

In case you skipped to this section, if you already have an investment in skills and/or artifacts based on standard WLP Beehive Page Flows, go back and read the first three paragraphs under the No Going Back for Wizard Lovers heading to add the JSF facet and understand the implications.

With the JSF facet installed, you are now free to develop JSF pages. There is no single wizard like for a Page Flow that will generate all of the base files you need for JSF development. You will need to create your backing beans by hand, although you will still have the standard Eclipse code assist tools. If your development team works from static HTML files, you can use a wizard that will create the JSF JSP for you. The wizard can be started from NewOther, expanding JSF and selecting Convert HTML to JSF:

Figure 2: HTML to JSF Wizard

The wizard simply adds the basic JSP declaration, JSF taglibs, and wraps the HTML in a view tag:

<%@ page language="java"
         contentType="text/html; charset=ISO-8859-1"
         pageEncoding="ISO-8859-1" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
<%@ taglib uri="" prefix="h" %>
<%@ taglib uri="" prefix="f" %>
      <meta http-equiv="Content-Type"
            content="text/html; charset=ISO-8859-1">
      <title>Insert title here</title>
      <form action="htmlBaseExample.jsp" method="post">
            Type in me:<input type="text" name="test"/><br />
            Check me:<input type="checkbox" name="checkMe"/>
      <table border="1" cellpadding="5" width="300">
         <tr><th>Field 1</th><th>Field 2</th></tr>
         <tr><td>Value 1</td><td>Value 2</td></tr>

Although there is also a wizard node for generating a JSF configuration file, one was already created by adding the JSF facet. WorkSpace Studio has a fairly comprehensive GUI for managing faces-config.xml.

Figure 3: WorkSpace Studio Faces GUI

With a JSF JSP in focus, the Design Palette will list all of the available tag libraries for drag-and-drop style development. If you are new to JSF, it sometimes will be more productive to write your first tag calls by hand to gain the understanding of what values to use for which options. Once you understand how the libraries work, the DP will save you a great deal of typing.

Having updated faces-config.xml with the proper references to your JSF page and backing bean, follow the steps described under Creating a JSF Portlet and you are done.

When to Use What

I want to start off by saying there are almost definitely considerations not covered here. These are things I have thought of while commuting or have heard people discuss around a single project where they were evaluating the options of using JSF in WLP.

The Beehive Page Flow Approach

The two main reasons to take the Beehive path is to provide a faster path for developers already familiar with Workshop but new to JSF and to take advantage of the rapid development tools that Page Flows offer. You also can use many of the NetUI libraries on the JSP, another productivity boost.

If you are already familiar with JSF, some of the API differences will take getting used to. The backing bean APIs are similar but different from the standard JSF backing APIs.

Standard JSF Development

Towards the start of this article, it was mentioned that while early adoption is cool, your early successes may not fit into the standardized future. Even though the Beehive approach does follow standards and uses open source rather than proprietary libraries, it is likely the tools will change and possibly the APIs will, too. Where the Beehive approach is the better choice for developers well-schooled in WLP development, if you are already proficient in JSF development there is nothing in WLP preventing you from using the skills you already have, and a few tools to allow you to be more productive with that experience.

Wait for the New Standards

There are two mutually exclusive and equally valid philosophies about what to do when you are uncertain. One is to do anything different, expecting to change your outcome and gain additional feedback. The other is to do nothing and let the situation work itself out. JSF is a break-out technology because it is based on standard tools available in J2EE. The servlet/JSP architecture gained its popularity the same way (ready to feel old?) back at the turn of the century. The servlet/JSP approach is still going strong, though very few developers use the base APIs anymore. Most of us use frameworks that extend those APIs for rapid development, and most of those frameworks are mature enough where they are portable. Even when standards are complete, the tools to implement those standards take some time to mature. JSR 168 promised portable portlets, although portlets that implement that standard are only now becoming truly portable.

JSF is mature enough to have some good frameworks available, some of which are even fairly portable (proof that the industry does learn from its mistakes). But, JSF portlets are still in their Wild West stage, and may not support your requirements. Not all JSF frameworks can be used in portals, and those that do seldom work in all portals, even the FOSS frameworks. Sure, a good developer can almost always find a way to make it work, but it will take time away from delivering on requirements and most likely have to be changed once the standards are commonly implemented.


My crystal ball has always been cloudy, and when it is clear it is just as likely to show the future of a parallel universe as the one this article is in. Odds are good that the future of JSF portlets will come to pass. The only question is if it is worth acting on that future today. That is a decision that is best based on the needs of today.

About the Author

Scott Nelson is a Senior Principal Consultant with 12 years of experience designing, developing, and maintaining web-based applications for manufacturing, pharmaceutical, financial services, non-profit organizations, and real estate agencies for use by employees, customers, vendors, franchisees, executive management, and others who use a browser. He also blogs all of the funny emails forwarded to him at Frequently Unasked Questions.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories