Neil Griffin

Lightning fast portlet development with JRebel

2011-07-22T22:16:38Z

Back in April of this year I had the opportunity to speak at the CON-FESS conference in Vienna, Austria. One of the exhibitors there was zeroturnaround.com and I had the privilege of sitting next to founder Jevgeni Kabanov over dinner one night.

Jevgeni described the benefits of JRebel, a JVM-plugin that makes it possible for Java developers to instantly see any code change made to an app without redeploying. Needless to say, redeploying WARs is part of the very fabric of a Liferay portlet developer's life, so I knew that I had to give this product a try with my next ICEFaces 2 portlet with PortletFaces Bridge.

and to my utter amazement... IT WORKED!!!

Simply put, this product is a MUST HAVE for Liferay portlet developers. I'm hooked! Over the past 6 years of portlet development, this product could have saved me COUNTLESS hours of development time waiting for redeploys.

The JRebel documentation is quite good, but here are some quick instructions for how to get started with JRebel and the Liferay+Tomcat bundle:

Download JRebel (30 day free trial)
Install JRebel to it's default location. For example, on the Mac: /Applications/ZeroTurnaround/JRebel

Set the REBEL_HOME environment variable. On the Mac, I find it's best to do this inside the $HOME/.MacOSX/environment.plist file:

		<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"> <dict>
<key>REBEL_HOME</key>
<string>/Applications/ZeroTurnaround/JRebel</string>
</dict>
</plist>

On Mac, add the following to the LIFERAY_HOME/tomcat/bin/setenv.sh script:
```
		-javaagent:$REBEL_HOME/jrebel.jar
```
On Windows, add the following to the LIFERAY_HOME/tomcat/bin/setenv.bat file:
```
		-javaagent:%REBEL_HOME%\jrebel.jar
```
Create a rebel.xml file that will be deployed in the runtime classpath of the WAR:Note that if you install the JRebel plugin for Eclipse, IntelliJ 8/9, IntelliJ X, or NetBeans) you can right click on the project and have the IDE generate the file. You can also generate the rebel.xml file with a Maven goal.
- Maven: src/main/resources/rebel.xml
- Liferay Plugins SDK: docroot/WEB-INF/src/rebel.xml
Start Tomcat with the liferay/tomcat/bin/startup.sh script (startup.bat on Windows)
Deploy the WAR to the Liferay /deploy folder
Make some Java code changes to your app and click Save in your IDE
Reload your browser, and voila! Instant changes! No redeploy!

Working with JSF's and java.util.Date

2010-07-30T20:50:39Z

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.

JSF 2.0 Complete Reference, with JSF Portlet Appendix

2010-07-30T20:51:19Z

I'm pleased to announce the new JSF 2.0 Complete Reference book by Ed Burns and Chris Schalk, published by McGraw-Hill. During the planning stages, Ed asked me to be a contributing author and help bring the first edition of the book up-to-date with JSF 2.0, and also to write a JSF Portlet Appendix.

As listed in the Table of Contents, Appendix A discusses the following Topics:

Overview of Portlet 1.0 and 2.0
- Portlet Lifecycle
- Portlet Modes
- Portlet Window States
- Portlet Preferences
- Inter-Portlet Communication
JSF Portlet Development
- JSF Portlet Bridges
- JSF Portlet View Handlers
- JSF ExernalContext and the Portlet API
- JSF and Portlet Preferences
- JSF and Inter-Portlet Communication
ICEfaces Portlet Development
- ICEfaces Ajax with Partial Submit
- ICEfaces Direct-to-DOM RenderKit
- The ice:portlet Tag
- ICEfaces 1.x Portlet Bridge
- ICEfaces 1.x D2DFaceletViewHandler
- ICEfaces 1.x and Portlet Window States
- ICEfaces Portlets and Concurrent DOM Views
- ICEfaces 1.x Extended Request Scope
- ICEfaces Ajax Push and Inter-Portlet Communication
- ICEfaces Themes and Portal Themes
- ICEfaces Themes and Liferay Themes
- ICEfaces Ajax Bridge and Liferay Portal
- ICEfaces Portlets and Liferay Request Attributes
PortletFaces
- Downloading PortletFaces
- PortletFacesContext
- PortletFaces Tags
- PortletFaces and Portlet Preferences
- PortletFaces and Expression Language Additions
- PortletFaces and Localization
- Liferay Language Portlet Integration
- Improved Integration Between Liferay and ICEfaces 1.x

This week (Feb 2nd to Feb 5th) Ed Burns & Chris Schalk will be helping to answer questions about the new book at JavaRanch. In addition, JavaRanch will be giving away a free copy of the book.

Finally I'd like to express my gratitude to Liferay, ICEsoft, Mimacom, and Triton for their generous support in making the JSF Portlet Appendix possible.

JSF 2.0 + ICEfaces 2.0 + Portlet 2.0 = The PortetFaces Bridge

2010-02-19T19:33:30Z

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:

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.