During a recent class I taught on ICEfaces, one of my students asked me why the calendar was often one day off from what got posted back to the model managed-bean setter.

For example:
// Facelets XHTML Markup:
<ice:selectInputDate value="#{modelManagedBean.dateOfBirth}">
    <f:convertDateTime pattern="MM/dd/yyyy" />
</ice:selectInputDate>

// Java Code
import java.util.Date;
public class ModelManagedBean {

  private Date dateOfBirth;

  public Date getDateOfBirth() {
    return dateOfBirth;
  }

  public Date setDateOfBirth(Date dateOfBirth) {
    SimpleDateFormat dateFormat = new SimpleDateFormat("MM/dd/yyyy hh:mm z");
    // The value printed here during postback was often wrong by 1 day
    System.out.println("dateOfBirth=" + dateFormat.format(dateOfBirth));
    this.dateOfBirth = dateOfBirth;
  }
}

Basically, the JSF DateTimeConverter Javadoc states that if the timeZone attribute is not specified, then the default is GMT. But when you create an instance of java.text.SimpleDateFormat, the default TimeZone is equal to TimeZone.getDefault() which (for me) was EST. So the solution I explained to my students was to make sure we were comparing apples-to-apples the whole way through, by using GMT for the SimpleDateFormat printing, like this:

dateFormat.setTimeZone(TimeZone.getTimeZone("GMT"));

And of course, I think it's the recommended practice to run your application server JVM in GMT. That would eliminate the problem entirely. But when you're using Eclipse and Tomcat for development, that's typically not the case.

UPDATE#1: PortletFaces Bridge webinar took place on Thursday, Feb 11 2010 AD. Click here to view the PDF slideshow.

UPDATE#2: The source code is at Alpha1 status and can be checked out from SVN here:

• http://svn.portletfaces.org/svn/portletfaces/bridge/org.portletfaces.bridge.api/trunk/
• http://svn.portletfaces.org/svn/portletfaces/bridge/org.portletfaces.bridge.impl/trunk/

I'm working on a new project called the PortletFaces Bridge which will enable the use of JSF 2.0 within Portlet 2.0 compliant portals like Liferay 5.x. The bridge implements a subset of the features available in JSR-329. Although the JSR-329 standard defines an API for a JSF 1.2 + Portlet 2.0 bridge, the PortletFaces Bridge is targeting JSF 2.0. Additionally, the bridge will facilitate usage of ICEfaces 2.0 within Liferay Portal.

Project Status as of January 27, 2010 AD:

• I have a sample JSF 2.0 portlet developed that is using the new PortletFaces Bridge.
• HTTP GET of portal page: bridge runs the portlet RENDER_PHASE, which runs the JSF lifecycle+renderResponse and the portlet renders fine in the browser.
• HTTP POST after clicking h:commandButton: bridge runs the portlet ACTION_PHASE, which runs the JSF lifecycle. It then runs the portlet RENDER_PHASE, which runs the JSF renderResponse and the portlet renders fine in the browser.
• RESOURCES: When using the new JSF 2.0 "resource" mechanism (like for downloading the "jsf.js" JavaScript file), the bridge correctly invokes the portlet RESOURCE_PHASE, which invokes the JSF 2.0 ResourceHandler and the contents of the requested resource are correctly delivered back to the browser.
• AJAX: After tabbing-out of a field, the JSF 2.0 "jsf.js" JavaScript code correctly invokes the portlet RESOURCE_PHASE, which runs the JSF lifecycle+renderResponse, and correctly applies the DOM updates in the browser. Currently it uses the new JSF 2.0 <f:ajax /> tag to do Ajax requests. BTW I had to fix a problem in Mojarra to make this work -- I'm in contact with the Mojarra team and they're working on fixing it for the upcoming 2.0.3 release.
• What's left: There's a bunch of little things -- loose ends that need to be coded up. Stuff like:
  • Testing of ICEfaces 2.0 WITHOUT the <f:ajax /> tag
  • Testing of ICEfaces 2.0 components (compatibility components)
  • Testing of ICEfaces 2.0 Ajax Push
  • After navigation-rules fire, need to compute the next JSF viewId to render
  • Detecting portlet mode changes (VIEW MODE, EDIT MODE, HELP MODE)

The goal is to have an Alpha version ready for use by the time the webinar happens on Thursday, Feb 11 2010 AD. The bridge will be be an open source project and be available for download from the http://www.portletfaces.org website.

I'm pleased to announce that the PortletFaces project has now been formally established and can be found here: http://www.portletfaces.org

An ICEsoft+Mimacom webinar has been scheduled for Thursday October 29, 2009:

4PM - 5PM CET
11AM - 12PM EDT
8AM - 9AM PDT

Here's the registration link: https://www1.gotomeeting.com/register/741441337

I'll be conducting the webinar along with Micha Kiener of Mimacom, sponsor of the Edoras Framework.

The goal the PortletFaces project is to make it easier to develop JSF portlets that run within Liferay Portal. The project contains a wealth of features that expose the standard features of the Portlet 2.0 API and vendor-specific features of Liferay in a way that is natural to JSF development. It also provides improved integration between Liferay and ICEfaces 1.x portlets.

The beginnings of PortletFaces can be traced back to a forum post made by community member Joel Kozikowski back in May of 2007. Joel donated his code to Liferay and we began to work on the project together under Liferay incubation. Since then, PortletFaces has been adopted by Mimacom AG and is a sub-project of the edoras framework.

I'd like to personally thank Joel and the other contributors for their valuable additions to PortletFaces:

• Micha Kiener
• Atul Patel
• Ed Shin
• Stefan Niederhauser

Also my personal thanks to Liferay for sponsoring PortletFaces during incubation, ICEsoft for all the terrific support, and thanks to Mimacom for adopting the project.

Finally, I'd like to thank Triton's Steve Groninga for coming up with the PortletFaces project logo.

Documentation for PortletFaces can be found here: http://www.portletfaces.org/documentation