The Beginning

When we started OcpSoft, we were working on what is now ScrumShark – using JSF 1.2 , Hibernate, and many other technologies.  At first it was very overwhelming, challenging to figure out which technologies to use; though, even after we had chosen our technology stack, we fought with poor documentation, lack of support, and integration as we explored new features of the stack.

During that time Lincoln saw a need for pretty URLs, because what was currently on the market wasn’t intuitive, and was painful to work with.  The enhancements we requested weren’t getting approved or were too slow coming, even providing patches.  So Lincoln set out to do it himself, and as he puts it: “destroyed Thanksgiving 2008.”

PrettyFaces

Thanks to PrettyFaces, Lincoln dug-in to JSF and started to really understand the inner workings of both problem and solution; within a few weeks of releasing version one, we were seeing many supporters.  Soon after, Lincoln was contacted by Dan Allen from JBoss/Red Hat, and started assisting him with an enhancement to JSF’s navigation system.

During that same time Lincoln convinced us – at OcpSoft – to start using JSF 2 Beta to build ScrumShark.  JSF 2 was undergoing continuous changes at that time, and the specification wasn’t even public, so we were seeing different results in our application every week.  Lincoln started posting the issues on the JSF 2 mailing list, and quickly became known as the JSF 2 tester, bug-finder.  Without ScrumShark, and Lincoln willing to take a chance on a bleeding edge technology, I don’t think the JSF 2 team would have found and fixed all the bugs as fast as they did.  Not too long after this, he joined the JSF Expert Group and was presenting PrettyFaces at JSFSummit.

Congratulations Lincoln!

He just got a job with JBoss at Red Hat, as a Senior Software Engineer. I am proud of of what my partner and best friend Lincoln has accomplished.

Goals of the site

• Provide a definitive starting point for users to get involved with JSF.
• Provide information “About JSF”, Information about the Spec, “Getting Started”, “Documentation”, “FAQ”, Community Involvement, and anything else that we all think necessary to engage and promote our user-base.
• The site will “out-link” as appropriate to additional resources.
• Promote ourselves as a competitive/welcoming solution in the Java-web framework community, both at the corporate and consumer/developer level.

Intent:

We intend for this site to be comparable to http://php.net and http://grails.org, to look and feel attractive, and to really draw people into the JSF world. There are some resources on the way to help get this shell/stopgap site off of google sites, and on to a real web-server, with real functionality, and a smooth look & feel.

It’s my personal goal to get this site written using JSF itself, and to make it the product of all of our ideas put together.

This site is for all of us, to benefit all of us, and the initial announcement is a little late. But if people ask how they can get started with JSF, we should all be pointing them to the same place: www.javaserverfaces.org

Why now?

Well it’s simple: Yes, we’re late, but better late than never. With JSF2 just released, and the JSFSummit Conference under-way, what better time to get people together around JSF2 during these two notable events?

I won’t get started about why this wasn’t taken care of when SUN first released JSF 1.0, but long story short, it’s getting fixed now.

What should we include on this site?

This depends on you, the community. Since JSF is the new Java EE 6 standard web-application framework, more and more people are going to be getting involved. What do you want to know? How can we best help you get started? Please let us know, and enjoy Like I said, JSF2 is a spectacular web framework – post your comments here and let us know what information you want to see about it.

How to get started in 5 minutes:

This is so simple, just check it out: http://www.javaserverfaces.org/get-started

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

With JSF2, it’s easy to accomplish!

This blog is based on Jim Driscoll’s blog, “Busy status indicator with JSF 2.” — for attaching a status to an individual event.

In your XHTML page, make sure that you output the JSF2 ajax libraries:

Now, in Javascript:

Make sure this javascript is only executed once per page, or you might get conflicting updates.

/**
 * ***************************************
 * Busy Status
 */
if (!window["busystatus"]) {
	var busystatus = {};
}
 
busystatus.onStatusChange = function onStatusChange(data) {
	var status = data.status;
 
	alert("ajax event triggered")
	if (status === "begin") { // turn on busy indicator
		document.body.style.cursor = 'wait';
	} else { // turn off busy indicator, on either "complete" or "success"
		document.body.style.cursor = 'auto';
	}
};
 
jsf.ajax.addOnEvent(busystatus.onStatusChange);

And that’s all there is to it! Your mouse cursor will now change to the hourglass when a user triggers any JSF2 ajax event.

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.

• 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!

Java Server Faces is currently full of relatively undocumented features and behavior. As part of the JSF2 release, OcpSoft is working with a few folks at Seam/Redhat to try to address these issues and provide better documentation.

If you have used, or currently use JSF, we need your help.

What did you find that was backwards from what you expected? What did you find that you couldn’t find anything about?

As we progress, we’ll compile the QA and make sure it gets preserved here, and on the official documentation site when it arrives, so that others don’t get lost on the same issues. It might even make it into the JSF2 specification if it needs to be fixed!

We’ll start it out:

“I used the JSF DateTimeConverter to format an input field into a Date, but the dates were sometimes one day behind. Why?”

You need to specify the timezone in each converter:

JSF1.x uses UTC by default. It does not use the server timezone!

<f:convertDateTime timeZone="America/New_York"  ... />
 
--or using a bean to specify the timezone based on the current user--
 
<f:convertDateTime timeZone="#{settingsBean.userTimezone}"  ... />

JSF2 will be addressing this issue at a configuration level, so adding timezones to each converter will no longer be necessary, but until then, you may want to think about writing a custom converter yourself.

If you need to use XML markup in your comment, please encode it first!

Otherwise it will disappear completely

“The community was speaking, but until recently, nobody was listening.”

A lot has changed since May 15, 2001, when the first ballot review of the JSF 1.0 framework was just beginning. To this day, Sun’s flagship web-application framwork has been an uncompromising box of tricks and gotchas, with little community adoption. This has been mostly due to its relatively developer-unfriendly nature; however, the second phase is coming, and with JSF2.0 peeking out from the edge of its nest, a new life is beginning to show.

From the start, JSF had mixed support from the community, with opposition from major players like IBM, HP, and the Apache Foundation. Apache voiced strong concerns because of “Sun’s current position that JSRs may not be independently implemented under an open source license.” In addition, they saw, “little value in recreating a technology [Struts] in a closed environment that is already available in an open environment.”¹

Apache’s concerns drew several other players to vote against JSF, but the final vote still passed with a 10-5 margin (Accenture abstained from voting.) With the voting complete a short two weeks later, the first JSF expert group was formed.

Three months after the formation of the expert group, the first JCP community review was complete, and Sun’s new star web-framework was on its way to reality. On the side of the box was a label, which read, “Final release, May 2004: Warranty Void if Removed” It was done, and their hands were off.

But some things that should not have been forgotten, were lost.

Since JSF was engineered by companies like IBM and Oracle, major contractors in the industry, most of the emphasis was placed on creating a modular architecture that could be ‘easily extended’ and broken down into components. While technically sound, and well designed for large companies where developers are part of an assembly line, the community at large found JSF hard to use.

JSF lacked life-cycle extension; there are six defined phases, and if you need to add another one, you’re out of luck. Also lacking was easy component creation — Creating a component in JSF today requires modification of no fewer than four separate files, even more if you use a separate renderer class. You were on your own if you wanted to validate multiple form fields against each other.

Navigation rules were ungainly, and difficult to follow logically without a visual editor. Community documentation was almost a joke. Sun’s mailing list and forum are still the best places to find help. There are some very knowledgeable people, but nowhere to be found is what most developers find most useful: a central, persistent resource for documentation. I like PHP’s model – official documentation with community feedback in comments below.

The lack of bookmarking support is one of the most highly-criticised facets of JSF, which is where I got involved, leading me to create the PrettyFaces URL rewriting extension. If you need to be convinced of the collective dysfunction on this topic, look at the results of a google search for “jsf bookmark”. Yet, at the root of all this was something JSF lacked until very recently – something very important.

A set of ears.

The community was speaking, but until recently, nobody was listening. Blame JCP? Cay Horstmann thinks that the JCP needs to be more open to the community.²

Personally, I’m surprised that JSF wasn’t abandoned completely, which says in my mind, “they got something right.” The framework does a lot for you, but “I can’t figure out how to use it”, “it doesn’t do what I need,” and “everything takes forever.”. This is where we see the light, and JSF2 enters from stage left; a new star performer?

From the very start, JSF2 is different, more open. Ed Burns, Ryan Lubke, Jim Driskoll and other blogging developers can be thanked for engaging the community in a way that Sun has not done before.

Convention over configuration has taught us a lot. We might thank Ruby on Rails, or possibly a collective laziness, but the JSR314 Expert Group has taken it to heart. “EzComp” is JSF’s new component writing system, and yes, it’s “Ez”.

Jim Driscoll explains how to create a “click to edit” AJAX input field, like those so popularly seen on Flickr, or Facebook. (About 30 lines of XHTML, plus JavaScript.) Tag libraries no longer need to be defined manually; they will spring to life as needed, based on the names and interfaces of your components.

JSF2 is showing stunning promise and vision. This is just a small set of changes that will drastically improve the usefulness and adoption of JSF. When a rookie Java web-developer can pick up JSF2.0, in their IDE of choice, and write a small, useful application in a day, that’s when we’ll know they’ve gotten it right. Man, life is good… but.

Where are my bookmarks?

Ahh yes.

After learning about JSF2 in mid-October, I’ve been following very closely the changes and discussions around its new architecture, and how it can be ‘fixed.’ At the top of the wish list, among other contenders like “Fixing Navigation Rules,” and even above “Simplified component development,” is one very near to my heart: “Enhanced support for GET requests.”

I began work on PrettyFaces before learning that JSF2 was in progress, but not before I had evaluated the other options available from the community. Jboss Seam had a UrlRewriting feature, but I found it cumbersome, requiring too much configuration, and the added burden of learning the entire Seam framework was too much for me. RestFaces was an alternative that I tried for a while, but several design choices made it difficult to incorporate in a non-invasive way, and I was left writing lines and lines of code in order to compensate for its (albeit few) shortcomings.

Shocked, disappointment struck when I was contacted by a PrettyFaces user, disheartened, who urged me to contact the JSF2 expert group because they were close to abandoning bookmarking support for the next release, a full five years after the last specification update. How could they be considering omitting such a critical feature? It would surely finish off whatever damage had been done by the first 8 years of JSF’s mis-managed life, and it would be dead forever. “Long live Struts,” Apache would tout.

New life.

But fate struck, and before I could even begin to write emails, begging for reconsideration, I got another pop-up from my inbox.

From: Dan J. Allen – Jan 10, 2:50pm

Lincoln,

Hey there. I have recently joined the JSF EG by way of my employment with Red Hat. My first action was to submit a couple of proposals to make JSF more "website friendly". After all, that is what got me interested in Seam in the first place.

In the most recent proposal, I cited the statements you made in a recent blog post. I have attached that proposal to this e-mail as well as a related proposal. We are listening (at least those of us at Red Hat) and we are trying our best to improve JSF within the boundaries that we have to work (i.e., the JCP). The JSF EG was definitely dysfunctional in the past, but Ed Burns, Red Hat, and a handful of other members have really started to turn things around. Adding pretty URLs is definitely too big of a change at this point given the time constraints, but you may find these two proposals to satisfy many of your other concerns. Feel free to provide feedback to the JSF EG regarding the design changes.

-Dan

Dan is the author of Seam in Action, and from my interactions with him, a brilliant individual. If he isn’t rich already, in heart or on paper, he will be someday.

Struck by two emails on this subject in the same day, I “hurriedly” (from 11pm-2am) typed a response. Someone at RedHat was asking me for my feedback? Talk about an ego trip. My friends at work won’t let me hear the end of it.

The proposal was stunning. While still omitting Pretty URL rewriting, it contained in depth solutions for using query-string parameters (http://url?key=value) to bookmark pages within JSF. It lacked page-load actions, but that would follow, as we talked through the issues, in the next few days.

During the process of reviewing Dan’s proposals, providing feedback where I could, and wishing I weren’t just a part-time contributor, we worked through issues regarding usability, convention over configuration, and strategies for implementing the new functionality that would be required. Two weeks and 91 emails later, we had a draft of the spec, and off it went (via Pete Muir at RedHat) to the Expert Group for review.

The proposal was accepted; Dan’s job got even better. Within a week, he would have to implement his proposed specification, create a sample application, make any necessary changes to the spec, submit it back to the EG, and believe me, it was good.

Things yet to come.

JSF2 is still under review, and all of these changes may yet be changed, but I’m confident that the people in charge have heads on their shoulders, and that they are pointing in the right direction.

I’m impressed. Impressed by Dan Allen, Jim Driscoll, Ryan Lubke, and by Sun for starting to recognize that its developer community is its best chance at survival. JSF2 won’t have everything that we’ve asked for, but it will have the most critical features that the community has asked for. I’m impressed that it’s turning out so well: Component writing is truly easy; pages will be bookmark-able; templating is built in; and annotations are on the way to deprecating faces-config.xml for trivial tasks.

So what can Sun do next? Well. For starters, keep listening. Don’t limit ideas to people on its payroll. JSF2 will be a success if Sun gives users a voice.

The developer blogs are great, but we need a centralized place for core documentation. The site needs to be fast, and you should be able to easily register and contribute. Yes, it will take management and oversight, but we aren’t out to hurt anyone. Dear sun: “We like what you’re doing, and the direction in which we think you might be turning. We’re here to further the cause of software development, and guess what… If you listen to us… we’ll do it for free.”

Whether or not this happens, the future of JSF is in our hands.

–

1http://www.jcp.org/en/jsr/results?id=614

2http://weblogs.java.net/blog/cayhorstmann/archive/2009/01/a_call_to_fix_t.html