Introduction

I recently had the opportunity to launch an Amazon EC2 instance and setup Liferay & MySQL. There were a couple of hurdles that I had to overcome, so I thought I would share the solutions I came up with.

• Running MySQL on EC2 ephemeral storage while maintaining consistency
• Running MySQL on Amazon EC2 with EBS
• Building a Web Server on Amazon's EC2

Conclusion

The benefit of using this approach is that I didn't have to change any of the settings in the /etc/my.cnf configuration file. Also, I didn't have to fight the selinux security context problem. This approach can also be used for mounting other folders like /opt in order to utilize ephemeral storage.

If you have a Maven repository running under https with a self-signed certificate, then building a Maven project can report the following error:

Error transferring file: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

There was an Oracle blog posted by Andreas Sterbenz back on Oct 09, 2006 that helped me diagnose the problem, but that blog is no longer available. Thankfully Andreas' blog was re-posted here. For additional information, I found another blog post that was helpful.

Anyways, I fixed this problem by downloading and compiling the source for InstallCert.java and running the following command:

java com.aw.ad.util.InstallCert myhostname.mydomain.com

This generated a file named jssecacerts in the current directory.

On Windows/Linux, this file needs to be copied to the JAVA_HOME/jre/lib/security/ directory.

On Mac needs to be copied to the JAVA_HOME/lib/security/ directory.

After I did this, Maven was able to download the artifacts from the self-signed repository.

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!

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.