In summary: I would recommend buying this reference if you are a consumer, designer, UI-developer who is working with existing component libraries, Facelets or JSF 2.0, and not so much focused on creating custom Java-components of your own. I don’t, for every-day web-site components, see why you would need much more than what is featured between the covers of this book. Ian Hlavats does a fantastic job of making bringing JSF to the everyday development setting.

JSF 1.2 Components By Ian Hlavats Download Chapter 2: Facelets Components as a PDF

In detail:

Initially hesitant to buy a reference on components, I have to admit that I was surprised to learn so much by reading through this book. As a member of the JavaServer Faces 2.0 expert group, and a full-time software engineer, components are not my strong-suit. If you’re at all like me, then you’re probably asking yourself the same question I did:

“What can I learn in this book that I can’t find on Google? JavaServer Faces has a huge online community, and there’s a lot of information available already.”

It’s a valid question, but you should keep reading because this book offers something important that I rarely find in blog entries or wikis: “features you wouldn’t think to look for; features that you wish you’d thought of, or don’t know how to make yourself.” I wish I had found this book when I started using JSF, because I’d probably have been more comfortable, and much more productive with our component side of the life-cycle, so to speak; I discovered features of the framework, and pre-made UI-tools that I wish I’d known about years ago.

Things you’ll learn about:

Modal windows, menus, wizards and workflows, AJAX anything with Ajax4JSF, i18n and localization, gCal-like schedules with Apache Tomahawk, multi-field validation, calendars, charts and graphs, file-uploads, user permissions/security, skinning, styling, and all major component libraries are covered in this book (save PrimeFaces, which gets a mere mention.)

If you think you’re looking at “Just another book on JSF component writing,” that’s not entirely the case. This book provides real solutions, real examples on how to get started writing JSF applications using existing component libraries and plug-ins. There are two types of chapters in this book: tutorials and references. The tutorials will get you up and running with a quick example, while the reference sections go in depth on usage of individual components within each library.

You’ll also (as a bonus, in my opinion) get some appetite-whetting information on the JBoss Seam framework, which is a user-friendly and business-oriented extension to the Java EE technologies. I didn’t get a very good picture of all of the concepts until I actually looked at the code samples (downloadable here, or just follow the link in the preface,) but that’s hardly a strong criticism; though, it may have helped if the code samples were more explicitly, frequently referenced.

In the end “The title doesn’t lie”:

• I haven’t seen a more comprehensive book on component libraries and component writing made available to date.
• JSF2 component writing has been simplified, but if you want to supplement your app with everyday things like in-place editing, accordions, and more, you’re going to want good examples; this book provides examples in abundance (even examples of JSF2 EzComp, which is a dream to use. UI like it was meant to be)
• Even if components and UI design are not your strong-point, that is exactly why you should read this book; it makes component-based design easy to understand, and easy to implement.

The author covers many of the advancements in component writing and simplified configuration that are provided by JSF 2.0, but I would have liked to hear some information on the component behaviors model, and mention of integration with frameworks like CDI (JSR-299) and Spring; however, this is not entirely relevant to component writing, and plenty of information exists on sites like www.javaserverfaces.org or Google.

My one complaint is that for a book titled “JSF 1.2 Components,” it did not explain, or teach me how to create custom Java-based components, which are essential for complex behavior and interaction at some level. JSF 2.0 has done a good job of making Java-based components unnecessary, but this book is titled JSF 1.2 components, thus, I would have liked to see how to write a Java-based component in JSF 1.2.

End notes:

Make sure you check out www.javaserverfaces.org. It’s a great starting point and reference for JSF that you will undoubtably bookmark if doing a lot of work, and doing the work with this book. Also check out http://ocpsoft.com/prettyfaces/ for more information on Pretty URLs in JSF, and building client-facing JSF web applications.

<ui:repeat> allows iteration over a List of Array[] of items, but it does not provide a method of discovering the “selected” or “actioned” row; there’s no way to discover the row the user is interacting with. Or is there?

I’ve since learned of two ways to deal with this situation:

1. Use ListDataModel

I asked another JSF Expert, Dan Allen (author of Seam in Action) and here’s what he told me:

@ManagedBean
@SessionScoped // chosen for convenience, really it should be view-scoped or conversation-scoped (299)
public class FeatureList
{
	private DataModel features;
 
	public DataModel getFeatures() 
	{ 
		return features; 
	}
 
	public String load() 
	{
		List l = new ArrayList();
		l.add(new Feature("One"));
		l.add(new Feature("Two"));
		features = new ListDataModel(l);
	}
 
	public void action()
	{
		System.out.println("You clicked on the button in the row with feature " 
			+ ((Feature) features.getRowData()).getName());
	}
}

@DataModelSelection Feature selectedFeature;

From Dan’s email, I learned that you could place a List of objects in a ListDataModel wrapper, effectively binding the state of the list to the UI. With that done, you can manipulate the data in an action-method, being able to retrieve the selected row index, object itself, and continue as you would expect with your programming.

2. Upgrade to an advanced EL (EL2) Jar

Probably my favorite solution – you can use EL2 method invocation, provided either by Seam, or Sun’s reference implementation, and pass the desired objects directly to methods in your JSP/Facelet code. It’s coming standard in J2EE 6, but why wait?

This method is simple, intuitive, and enables much more powerful and reusable Beans to handle page code, reducing redundancy in Model classes and business logic.

Note how I pass the current var object directly to the method via EL:

<h:commandButton id="add" value="Add Task" 
    action="#{itemController.addItemNote(currentItemBean.item, addNoteBean.newNote)}">

And here’s the Backing Bean code:

@ManagedBean
@RequestScoped
public class ItemController
{
    public String addTask(final Item item, final Note note)
    {
        ItemService.addNote(item, note);
        return "pretty:viewItem";
        // this return statement is a PrettyFaces JSF bookmarking navigation id
    }

For instructions on how to: include EL2 in a JSF project go here.

For more information on JSF SEO and Bookmarking, take a look at PrettyFaces: URL rewriting extension for JSF.

If you are at all confused by these examples, feel free to leave a comment, and I’ll do my best to help.

Looking for real-world experiences:

• How has PrettyFaces helped you or your team?
• What would you change if you could (you can)?
• If you would like to share, show us your work of art!

Email to: lincoln@ocpsoft.com

Thank you!

PS – In addition: If you’d like to be added to our new “People using PrettyFaces” page, also send a logo and a short description of your product or company!

A new version of PrettyFaces for JSF1.1 (historical support) is now available for download. This version is feature-complete, but we are looking for feedback on compatibility and functionality that may be broken with various implementations, so please post comments!

It should be noted that JSF is now on version 2.0, and PrettyFaces 2.0.x should be used. E.g: PrettyFaces 1.2.x should be used with JSF 1.2.

1.1.0: jar, src

You may even want to go so far as to completely UN-set the FacesContext from the current thread. We would do this by calling FacesContextBuilder.removeFacesContext()

Call FacesContext.release() when you are done!

FacesContextBuilder.java

public class FacesContextBuilder
{
    public FacesContext getFacesContext(final ServletRequest request, final ServletResponse response)
    {
        FacesContext facesContext = FacesContext.getCurrentInstance();
        if (facesContext != null)
        {
            return facesContext;
        }
 
        FacesContextFactory contextFactory = (FacesContextFactory) FactoryFinder
                .getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
        LifecycleFactory lifecycleFactory = (LifecycleFactory) FactoryFinder
                .getFactory(FactoryFinder.LIFECYCLE_FACTORY);
        Lifecycle lifecycle = lifecycleFactory.getLifecycle(LifecycleFactory.DEFAULT_LIFECYCLE);
 
        ServletContext servletContext = ((HttpServletRequest) request).getSession().getServletContext();
        facesContext = contextFactory.getFacesContext(servletContext, request, response, lifecycle);
        InnerFacesContext.setFacesContextAsCurrentInstance(facesContext);
 
        return facesContext;
    }
 
    public void removeFacesContext()
    {
        InnerFacesContext.setFacesContextAsCurrentInstance(null);
    }
 
    private abstract static class InnerFacesContext extends FacesContext
    {
        protected static void setFacesContextAsCurrentInstance(final FacesContext facesContext)
        {
            FacesContext.setCurrentInstance(facesContext);
        }
    }
 
}

 
FacesContext wraps the HttpServletRequest with its own RequestWrapper, and when attempting to hold on to references to any response through a Servlet Forward (via RequestDispatcher), bad things will happen.

For example:

When using the PrettyFaces URL bookmarking/rewriting utility (who’s PrettyFilter relies on Servlet forwards) any FacesContext created before this forward occurs will be left open, and sporadic NullPointerExceptions will occur depending on Request thread timing in the Servlet container.
 

Caused by: java.lang.NullPointerException
at org.apache.catalina.connector.Request.setAttribute(Request.java:1424)
at org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:503)
at javax.servlet.ServletRequestWrapper.setAttribute(ServletRequestWrapper.java:284)
at com.ocpsoft.pretty.PrettyContext.setCurrentInstance(PrettyContext.java:93)
at com.ocpsoft.pretty.PrettyContext.getCurrentInstance(PrettyContext.java:84)
at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:58)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
...

 
Or sometimes request attributes will be missing entirely, even if the request is accessible.
 
In order to safely navigate FacesContext in a ServletFilter, make absolutely sure that you release() and remove the context when you are done with it. Then you get happy applications working together with other frameworks!
 
Cheers, happy developing!

UPDATE: There is a simpler, but less complete solution built in. (See here.) This means appending “?spring-security-redirect=/your/target/url” to your redirect to the Spring Security Filter chain.

If you have not already completed integrating Spring Security and JSF, please consider it, as this article depends on having a working JSF login page and managed bean.
 
Note: This approach will not work if you are invalidating/re-creating the session after a successful authentication (see Session Fixation attacks). Supporting session invalidation would take some extra work that will not be in the scope of this article.

The login form

Here is a basic JSF/Spring Security login form. It would be nice if we could enable or disable the redirect functionality, so we’ll add a hidden form field that is only rendered on demand (here we use Facelets ui:param functionality for our on-off switch.)
 

<h:form prependId="false">
    <c:if test="#{redirect == 'true'}">
        <input type="hidden" name="redirect" value="true" />
    </c:if>
    
    <label for="j_username"><h:outputText value="Username:" /><ocp:message
        for="j_username" /><br />
    </label>
    <h:inputText id="j_username" value="#{loginBean.username}"
        required="true" />
 
    <br />
    <br />
    <label for="j_password"><h:outputText value="Password:" /><ocp:message
        for="j_password" /><br />
    </label>
    <h:inputSecret id="j_password" value="#{loginBean.password}"
        required="true" />
 
    <br />
    <br />
    <label for="_spring_security_remember_me"><h:outputText
        value="Remember me" /> </label>
    <h:selectBooleanCheckbox id="_spring_security_remember_me"
        value="#{loginBean.rememberMe}" />
    <br />
 
    <h:commandButton type="submit" id="login"
        action="#{loginBean.doLogin}" value="Login" />
 
    <h:commandButton type="submit" styleClass="faded" id="cancel"
        action="#{loginBean.doCancel}" value="Cancel" immediate="true" />
    <br />
    <br />
</h:form>

The login action method

First, check to make sure that we actually want to do a redirect after login. Do this by testing for the existence of our hidden form parameter.
 
Find the full LoginBean code here.

public String doLogin() throws IOException, ServletException
{
    String redirect = FacesUtils.getRequestParameter("redirect");
    if ((redirect != null) && !redirect.isEmpty())
    {
        redirect = PrettyContext.getCurrentInstance().getOriginalRequestUrl();
        Map<String, Object> sessionMap = FacesContext.getCurrentInstance().getExternalContext().getSessionMap();
        sessionMap.put(LoginRedirectFilter.LAST_URL_REDIRECT_KEY, redirect);
    }
    FacesUtils.getExternalContext().dispatch("/j_spring_security_check");
    FacesUtils.getFacesContext().responseComplete();
    return null;
}

 
Before forwarding to the Spring Security /j_security_login_check intercepting filter chain, we’ll need to set the current URL into a Session attribute: “LoginRedirectFilter.LAST_URL_REDIRECT_KEY”.
 
This will be used in our custom filter after the user successfully authenticates with Spring Security.

The login filter

Here is where we’ll check for the existence of our session attribute: “LAST_URL_REDIRECT_KEY”. If this key contains a value, then we should redirect the user to that URL. If the key does not contain a value, then we should not perform any redirect, and continue as normal.
 
One other concern is: what if authentication failed? Let’s assume that Spring Security will redirect the user to the Login Page if they send invalid credentials. We don’t want to trigger a redirect as they try to access the login page, so we also check to make sure we have a successfully authenticated user before redirecting.
 

import java.io.IOException;
 
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
 
import org.springframework.security.authentication.AnonymousAuthenticationToken;
import org.springframework.security.core.Authentication;
import org.springframework.security.core.context.SecurityContext;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.stereotype.Component;
 
@Component
public class LoginRedirectFilter implements Filter
{
    public static final String LAST_URL_REDIRECT_KEY = LoginRedirectFilter.class.getName() + "LAST_URL_REDIRECT_KEY";
 
    @Override
    public void destroy()
    {}
 
    @Override
    public void doFilter(final ServletRequest request, final ServletResponse response, final FilterChain chain)
            throws IOException, ServletException
    {
        HttpSession session = ((HttpServletRequest) request).getSession();
        String redirectUrl = (String) session.getAttribute(LAST_URL_REDIRECT_KEY);
        if (isAuthenticated() && (redirectUrl != null) && !redirectUrl.isEmpty())
        {
            session.removeAttribute(LAST_URL_REDIRECT_KEY);
            HttpServletResponse resp = (HttpServletResponse) response;
            resp.sendRedirect(redirectUrl);
        }
        else
        {
            chain.doFilter(request, response);
        }
    }
 
    private boolean isAuthenticated()
    {
        boolean result = false;
        SecurityContext context = SecurityContextHolder.getContext();
        if (context instanceof SecurityContext)
        {
            Authentication authentication = context.getAuthentication();
            if (authentication instanceof AnonymousAuthenticationToken)
            {
                // not authenticated
            }
            else if (authentication instanceof Authentication)
            {
                result = true;
            }
        }
        return result;
    }
 
    @Override
    public void init(final FilterConfig filterConfig) throws ServletException
    {}
}

Web.xml

Some specific configuration is required to ensure the proper ordering of our filters. LoginRedirectFilter’s filter-mapping must be placed after any Spring Security filters – otherwise we will redirect too soon, and authentication will never occur. You probably want to place it before any filters that apply business logic.

<filter>
    <filter-name>loginRedirectFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>loginRedirectFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Putting it all together

This sequence diagram describes the entire process, including what Spring Security will be doing after intercepting the /j_security_check forwarded from LoginBean:
You should now have a functional LoginRedirectFilter configured in tandem with Spring Security. Please feel free to post any suggestions or questions.

New versions of PrettyFaces for JSF1.2 and JSF2.0 are now available for download:

1.2.4_GA: jar, src

2.0.1_GA: jar, src

Minor Release: 20090613

1. Fixed non-redirecting faces-navigation integration.
2. Enhanced null handling for mis-configured viewIds
3. Now supports browsers with cookies disabled

• You can pass a value-binding into a component.
• You can assign a listener to a specific input field/button inside a custom component.
• You can pass facets into components and use them conditionally.
• You can attach validators to specific input fields/buttons of components.
• You can pass nested children into components and use them conditionally.
• In EzComp, namespaces are created automatically by convention — no more taglibs
• You can include CSS or JS files from packaged jars — a big issue when using shared libraries of components.
• Standard support for Ajax — no javascript required (<f:ajax />).

Without all of this, with JSP or Facelets 1.2, you eventually need to write components in Java, which means a lot of time-consuming work. Having gone down that road, and then experienced EzComp, I’ve seen a time-saving of about 10x, with a lot more power to create really interactive and rich components through Ajax. Instead of 3-4 files required to make a component, you now have 1 — the component.

Moral of the Story: If you are considering an upgrade from JSP, go right to JSF2 — it’s stable enough to begin development.

Also, be sure to check out the developer blags for more updates on JSF2:

• Ed Burns
• Ryan Lubke
• Jim Driscoll

Because the example had initially used the @PostConstruct annotation to trigger a method to handle the error message, the handleError() method was being called before the actual authentication event had taken place, thus, the handleError() method was triggering before any BadCredentialsExceptions were stored in the Session.

Instead of creating an error handling method in the LoginBean itself, instead attach a PhaseListener which will intercept failed logins, and add the new FacesMessage before the RENDER_RESPONSE phase.

LoginErrorPhaseListener

import javax.faces.context.FacesContext;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
 
import org.springframework.security.BadCredentialsException;
import org.springframework.security.ui.AbstractProcessingFilter;
 
impot util.FacesUtils;
 
public class LoginErrorPhaseListener implements PhaseListener
{
    private static final long serialVersionUID = -1216620620302322995L;
 
    @Override
    public void beforePhase(final PhaseEvent arg0)
    {
        Exception e = (Exception) FacesContext.getCurrentInstance().getExternalContext().getSessionMap().get(
                AbstractProcessingFilter.SPRING_SECURITY_LAST_EXCEPTION_KEY);
 
        if (e instanceof BadCredentialsException)
        {
            FacesContext.getCurrentInstance().getExternalContext().getSessionMap().put(
                    AbstractProcessingFilter.SPRING_SECURITY_LAST_EXCEPTION_KEY, null);
            FacesUtils.addErrorMessage("Username or password not valid.");
        }
    }
 
    @Override
    public void afterPhase(final PhaseEvent arg0)
    {}
 
    @Override
    public PhaseId getPhaseId()
    {
        return PhaseId.RENDER_RESPONSE;
    }
 
}

faces-config.xml

<?xml version="1.0" encoding="UTF-8"?>
<faces-config version="1.2" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xi="http://www.w3.org/2001/XInclude"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd">
	<lifecycle>
		<phase-listener>login.LoginErrorPhaseListener</phase-listener>
	</lifecycle>
</faces-config>

Happy developing!

Version 1.2.3_GA: binary, source, documentation (stable)
Minor Release: 20090415

1. Added optional <action onPostback=”false”> boolean flag to prevent action methods from being called on form postback. Defaults to true;
2. Added optional <query-param decode=”false”> to prevent java.net.URLDecode.decode() from being called on a specific managed query-parameter. Defaults to true;
3. Added unit tests for several critical classes.
4. Minor to moderate refactoring of PrettyFilter/PrettyContext