JSF Debugging

So you've cloned another JSF-based Sakai tool, or perhaps written it from scratch and it doesn't work. This page is a collection of notes on things you can check or do to get your JSF application to work. It's organized by symptoms, then by technique.

Errors Running Maven

Syntax Errors

Errors generated by the Java compiler usually supply enough information to resolve them. Most of these are not particular to JSF, unless it's an "unknown symbol" problem.

Dependency Problems

Unknown symbol problems are likely caused by missing dependencies in your project.xml file. Depending on use of Sun vs. MyFaces, you'll need to include the following:

Errors on Tomcat Startup

As of Sakai 2.2, the various code bodies (Enterprise Bundle, sakai_mini, sakai_training) are all optimized to avoid any exceptions at startup time. Watch catalina.out as Tomcat starts up for exceptions. These exceptions fall roughly into categories that follow.

Class Loader Errors

Class loader errors usually happen when a class needed by your application is missing. The usual cause for missing classes is not including them in your project.xml file. Check the list of modules listed in the "Dependency Problems" section above. If nothing seems to missing, you can figure out which modules are missing by figuring out:

1. What JAR or Sakai module the missing class is in.
2. If a JAR, your local maven repository can help you figure out the groupId, artifactId, and version.
3. if a Sakai module, look at the project.xml file for that module to determien it's artifactId. groupId is always sakaiproject, and the version number should be ${pom.currentVersion}

Initialization Errors

Properties in managed beans can be initialized by either JSF or Spring. Common problems here are mis-matched identifiers, missing setters, lack of a <managed-bean> tag, etc.

Other Tomcat Startup Errors

TBD.

Runtime Errors

JSF Runtime errors can take one of two forms: a Tomcat exception, and a JSF problem page.

Runtime Tomcat Exception

Uncaught application exceptions will often surface in catalina.out. Some exceptions will be caught by JSF, which may result in a JSF Problem Page, or a Blank Page.

JSF Problem Page

The Sakai JsfTool now displays a problem page with limited amount of information.

Blank Page at Runtime

Blank pages are a common problem in developing JSF-based applications. They reflect an inability of JSF to render your page for various reasons. There are actually two kinds of blank pages, which you can determine by looking at the page source: empty and XML pass through.

Empty Pages

If your page source is truly empty, you have a rendering problem. Check catalina.out and see if there are exceptions reported there. Warning: some JSF exceptions may be swallowed preventing rendering and NOT giving you a clue as to why.

JSF XML Pass-through

If your page source contains JSF XML markup, you have a different kind of rendering problem, likely related to the request processing chain.

The following code can be added to JsfTool.dispatch near the top to show the request path:

System.out.println ("\n\n****** JsfTool:  target:  "+target);

The logger can provide some information if enabled. There is a log4j.properties file in util/util-impl/src/conf that's used to control logging level details. Add list line to watch logging from JsfTool

• log4j.logger.org.sakaiproject.jsf.util.JsfTool=DEBUG

However, this doesn't give you a lot of data to work with.

Listener Errors

On 4/24/07, Dave Ross <dave.ross@gmail.com> wrote:

I'm trying to get a 2.4 test server going, and I'm unable to get a successful start of any of the JSF tools. Otherwise, everything starts normal. For every JSF app, I get the following stack trace:

I've tried different versions of tomcat: 5.5.17 (which we run in production on 2.3.x), 5.5.20, 5.5.23 - all net the same. I've tried with and without the compatibility pack (which I understand is not a requirement for 2.4.x) - with the compatibility pack I get an immediate shutdown of Tomcat during startup. OS is Windows XP and I've tried on Win2k3 Server with the same result.

As a follow up - I've been doing some reading and the recommended fix is to put a

<listener>
     <listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>

into web.xml (see http://www.evolutionnext.com/blog/2005/03/06.html). Surely there must be some other way to fix this? Is it a global tomcat
startup setting that needs to be changed (I'm using OOTB settings other than typical jvm memory tuning).

Are you putting the extra configuration bit into the web.xml for a particular context (such as the tool you're working with)? If so, you may be able to make the change globally by adding it to conf/web.xml instead.