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:

1. Download JRebel (30 day free trial)
2. Install JRebel to it's default location. For example, on the Mac: /Applications/ZeroTurnaround/JRebel
3. 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>

4. On Mac, add the following to the LIFERAY_HOME/tomcat/bin/setenv.sh script:

   		-javaagent:$REBEL_HOME/jrebel.jar

5. On Windows, add the following to the LIFERAY_HOME/tomcat/bin/setenv.bat file:

   		-javaagent:%REBEL_HOME%\jrebel.jar

6. 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
7. Start Tomcat with the liferay/tomcat/bin/startup.sh script (startup.bat on Windows)
8. Deploy the WAR to the Liferay /deploy folder
9. Make some Java code changes to your app and click Save in your IDE
10. Reload your browser, and voila! Instant changes! No redeploy!

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.