Support for cloud deployment of RichFaces based applications was one of the hot topics for a long time and finally it’s there! Actually the development was mostly completed a month ago and was already announced at Java One sessions. The official announcement was postponed in order to stabilize the feature and to create a special archetype to make it an easy start.

Let’s review what was done and the steps which should be performed to deploy your RichFaces application to Google Application Engine.

Restrictions of GAE deployment

Google Application Engine deployment introduces some restrictions for the Java developer. Here are some of them which are important for us to get started:

How to avoid Java2D? Maven plugin for resources generation.

One of the most important restrictions which required additional development from our team was the Java2D usage restriction. RichFaces Skinning mechanism relies to these classes for dynamic resources generation to support application skinning. To meet GAE restriction without losing RichFaces look'n’feel flexibility a new Resource Plugin that creates static version of RichFaces resources was needed:

  • Substitute skin parameters to CSS for all skins used by application
  • Compress CSS files
  • Provides relative URLs in CSS
  • Generates skin images
  • Extracts all JavaScript files used by application and compress them
  • Generates descriptor for all processed files. RichFaces framework use this descriptor to point to appropriate resources (e.g. placed on external server/CDN)

Check plugin definition and configuration at generated application pom.xml (maven-resources-plugin)

All that is needed after that is to define static resource location in web.xml using context parameter like:


Note: that this can also be useful for serving resources from different servers to aid in scalability in production environments.

What should be considered additionally

There are some more points related to GAE restrictions. Some of them are not directly related to RichFaces usage but should be considered by any JSF developer:

  • Current push component architecture – does not support listener serialization.

So we still need to complete push architectural redesign in order to support cloud environment properly for that component.

  • Creation of new threads is not allowed

So trying to port some simple examples from 3.3.x directly which relies on threads (e.g. poll/push) – will not works.

  • Running JSF 2.0 at GAE requires some additional settings even without RichFaces 4.

Check that article from GAE knowledge base for details.

  • No write access to file system

Developer should configure cache to use Google Memcache implementation.

Archetype for GAE project generation and build

As was mentioned above, and at JavaOne we have created a special archetype in order to create JSF 2.0, RichFaces 4 application skeleton already configured for GAE deployment. To generate a project – just execute:

mvn archetype:generate -DarchetypeGroupId=org.richfaces.archetypes 
-DarchetypeArtifactId=richfaces-archetype-gae -DarchetypeVersion= 
-DgroupId=<yourGroupId> -DartifactId=<yourArtifactId> -Dversion=1.0-SNAPSHOT 

Now the project could be built using simple mvn install execution


  1. First released version of the archetype is in
  2. The readme.txt file contains instructions for deploying to GAE server, or using the local GAE SDK developer server for local testing.

Deploying applications to GAE account

In order to avoid copy and paste work – here is the link to official instructions which we successfully using for our tests deployments. If you already have your account created, application registered and GAE SDK configured properly:

  • Make sure you updated version in appengine-web.xml before redeploying
  • Execute appcfg update <path to exploded archive with application>
  • That’s it! Just go to your account and check that the application in place and working!

Get updates of my blogs in twitter

My blog

Back to top