Last Modified: December 30, 2011
This section discusses some of the problems you you will encounter when you try to use Sun Microsystem's Reference Implementation of the JavaServer Faces 2.0 framework on the Google AppEngine platform.
The following compatibility issues with the 2.0.6 release of Oracle's reference implementation of the JavaServer Faces 2.0 specification and the 1.6.1 release of the Google App Engine platform.
Thread Use in the JavaServer Faces Reference Implementation
By default, Sun's reference implementation (RI) for the JavaServer Faces (JSF) framework uses threads. When running under traditional Java runtime environments, this does not present a problem because threading is allowed. Unfortunately, applications deployed on the Google AppEngine
platform cannot start threads of their own. This is enumerated in the "Threads" sub-topic of the "Sandbox
" section of the "Java Servlet Environment
" document published on Google's web site (shown below).
A Java application cannot create a new
java.lang.ThreadGroup nor a new
java.lang.Thread. These restrictions also apply to JRE classes that make use of threads. For example, an application cannot create a new
java.util.concurrent.ThreadPoolExecutor, or a
java.util.Timer. An application can perform operations against the current thread, such as
The release notes
for the JSF 2.0 reference implementation updated with the release of the second beta describes the "com.sun.faces.enableThreading" configuration parameter which, when set to false, tells the framework NOT to use threads. Adding the following to an application's WEB-INF/web.xml configuration file will stop any attempts by the JSF framework to spawn additional threads.
<!-- Disable use of threading for single-threaded environments such as
the Google AppEngine. -->
When enabled, the runtime initialization and default ResourceHandler
implementation will use threads to perform their functions. Set this
value to false if threads aren't desired (as in the case of running
within the Google Application Engine).
Note that when this option is disabled, the ResourceHandler will not
pick up new versions of resources when ProjectStage is development.
If the com.sun.faces.enableThreading context parameter is not set to false (or omitted completely from the web.xml configuration file) an application deployed on the Google AppEngine will display a number of different errors all caused by the JSF reference implementation's attempts to construct threads.
NOTE: I mention (possibly earlier) because I have not been as diligent in testing these compatibility issues with each release. In updating the "Configuring JavaServer Faces 2.0 to run on the Google App Engine Using Eclipse" article to be compatible with the 1.6.1 release of Google's AppEngine platform, I added the javax.faces.PROJECT_STAGE context parameter with a value of "Development" and the template application deployed and ran successfully.
Setting the "ProjectStage" Context Parameter to Anything But "Development"
Resolved in Release: 1.6.1 (possibly earlier)
While the release notes
for the JSF 2.0 reference implementation indicate that setting the com.sun.faces.enableThreading context parameter equal to false will cause the "...ResourceHandle [to] not pick up new versions of resources when the ProjectStage is development.", practical experience has proven otherwise. When the javax.faces.PROJECT_STAGE context parameter is set equal to Development, the web application will fail to start and the logs available in the Google AppEngine console will contain the following error message.
com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! access denied (java.lang.RuntimePermission modifyThreadGroup)
While working with a pre-release version of the JSF 2.0 reference implementation, it is recommended that the javax.faces.PROJECT_STAGE context parameter be set to either or Production, UnitTest, SystemTest, or Extension. For example, a web application of an application deployed on the Google AppEngine with the following setting in the WEB-INF/web.xml configuration file will not have a problem.
This section describes items that have, in the past, been a problem when running JSF2 applications on the Google App Engine platform; however, they should no longer be a problem when using a modern version of the local development tools or the current server-side runtime.
BasisLibrary: Restricted Class Issue
Resolved in Release: 1.5.0
After configuring a web application to use the second beta of the JSF 2.0 reference implementation and deploying it to the Google AppEngine platform the application failed to start. The log files access through the application's AppEngine console reported the following error:
com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED!
com.sun.org.apache.xalan.internal.xsltc.runtime.BasisLibrary is a restricted class. Please see the Google App
Engine developer's guide for more details.
One solution to this particular problem was to place copies of the serializer.jar
files from the 2.7.1 release of the Apache Xalan-J
libraries into the web application's WEB-INF/lib
Another solution is to ensure that the web application's WEB-INF/web.xml file explicitly sets the following parameters:
JSP 2.1 Issue
Resolved in Release: 1.4.2
The Google AppEngine for Java SDK supports the JavaServer Pages
2.1 API specification
. Unfortunately, there is a difference between the Geronimo API jar (geronimo-jsp_2.1_spec-1.0.1.jar) and the Jasper implementation jar (jasper-runtime-5.0.28.jar). The Geronimo API jar supports the 2.1 API specificaion; however, the code contained in the implementation jar only supports the JavaServer Pages 2.0 API. This is documented in the Google AppEngine Issue 1506.
This problem manifests itself by displaying a java.lang.AbstractMethodError
) when the getJspApplicationContext
method is invoked on the javax.servlet.jsp.JspFactory
class. This happens when the web application starts up.
Fortunately, the problem can be fixed by explicitly defining the default Expression Language (EL) Expression Factory should be used via the com.sun.faces.expressionFactory web application context parameter in the web.xml.
The following text should be added to the WEB-INF/web.xml file of your GAE project.
In the grand tradition of practicing what you preach, the Google AppEngine for Java leverages the Datastore (built atop BigTable) and Memcache frameworks for session persistence. It seems that, over time, a small percentage of Datastore operations will fail.
When attempting to display a web page containing JSF input components, a "com.google.appengine.api.datastore.DatastoreTimeoutException" (sample stack trace
) may be encountered by your web application. Once this error page is encountered in your application, no other page will work until your session times out.According
to Don Schwartz
of Google, the next release of the Google AppEngine for Java will include "improved retry and error handling logic" that are intended to lessen the likelihood of frameworks such as JSF, Struts, etc. encountering this problem.
This problem still manifested itself in version 1.2.6
of the AppEngine SDK
. You can work around this problem by setting the following context parameter in your
There are costs and benefits to saving the view state in the client tier. The "JavaServer Faces" forum on forums.sun.com has a thread
that summarizes the difference between the
options for the
configuration parameter. Essentially, with the client option, view information is stored as a Base64 encoded value in a hidden field on your web form with the name
com.sun.faces.VIEW. Mert Caliskan's weblog discusses the pros and cons of storing state on the client or server.