JSF 2.2 with Google App Engine: A Hurricane of Errors

Three days trying to do what should be a simple upgrade from the JSP Hello World to JSF and it still isn't working.

Long story short, when you get started with Google App Engine you'll find a nifty tutorial from Google that gets you up and going with a simple Guestbook JSP project.  I use Maven with my Eclipse so I used the Maven Archetype instead (also JSP).  At the time I was unable to find a detailed tutorial that starts with JSF to begin with.  There will be a future post with my experience of using that one instead (UPDATE: done, see this post).

As is, I setup the configuration for JSF and Apache MyFaces doing it the old-fashioned, manual way.  I had problems finding documentation on how to do it (and couldn't even find it again).  So, this is what NOT to do:

  1. Include Apache MyFaces in your Maven dependencies.
  2. Update your web.xml to be at least version 2.5 (this is actually a good idea) and include the following
(UPDATE: below code is properly presented now)

  Faces Servlet
  javax.faces.webapp.FacesServlet
  1



  Faces Servlet
  /faces/*

  3. Put a simple JSF hello world file into your /faces directory and load it up.  Even better, don't use an EL #{} expression so that you don't know that EL is broken until much, much later.

As stated, this worked three years ago with Eclipse 3.6 or so, but NOW Eclipse 4.3 Kepler has a concept called Project Facets under the Project properties screen and if you don't specify that you're using JSF here... it blows away your custom web.xml to the default jsp version.  This was Gotcha #1.

After reverting that mess and configuring the Facet I'm expecting a smooth ride... but get the now dredded: javax.naming.InitialContext is a restricted class error, and try the fix suggested by the link just previous.  I do not catch the subtext that this fix is only for Sun's (not Apache's) JSF implementation, and for an older version than I'm using at that!  So I change to Sun's JSF, track down the new WebConfiguration.java and comment out the needed code and at least it compiles but it still doesn't work, so I go back to MyFaces, download the source and comment out their references that I track down.  Then I have to track down a couple of other libraries that the one source file uses and it finally compiles.  At least the Hello World works at this point.  Now I know that the more recent JSF implementations have this issue fixed!  So don't mess around with commenting out the InitialContext code, just change the JSF implementation (the latest Mojarra works).  If you're keeping track, these are Gotchas 2 to 7.

Upgrading to Facelets is as easy as it is supposed to be.  However, this is when I realize that my EL isn't working.  After trying and reading various articles I came across new errors.  I found that I got ClassNotFoundException: javax.faces.webapp.FacesServlet and the ELResolvers for JSF were not registered with the JSP container not because it could not be found, but because it could be found too often (and I had to include it as provided instead of as a jar).  The novel cannot_find_facelet_taglib turned out to just be an Eclipse thing.  All in all, I still wasn't able to patch it up after finding about 6-12 other gotchas.

Not as Easy as it Looks

After trying to migrate from JSF 1.2 to 2.0 with these StackOverflow questions I found that if you're upgrading to Facelets 2.0 you also need to upgrade to Apache Trinidad 2.0.

Maven info can be found at this post at Thoean.  It's supposed to have more content, but I couldn't figure out how to get to it.

It appears that that is the best upgrade guide that I could find, and this Andy Schwartz blog post is great for what features you get when it's all over.

Part 2 is about moving from OGNL to SpEL.

Components and Confusion in Facelets

The word component is used a lot in Facelets (and supporting technologies):

• Facelets Custom Tag
• Specially packaged ui:components or ui:compositions.
• Facelets ui:component 
• essentially just a ui:composition with a backing bean.
• Driven by xhtml with more tags.
• JSF Custom UI Components
• Subclasses of javax.faces.component.UIComponent.  
• Driven by Java backing beans (rendered as HTML via a renderer)
• backing beans are different from managed beans
• Creates a new tag to be used with xhtml.
• JSF Advanced Composite Components
• They're like a template (in the generic sense, not a ui:template).
• They mean the UIComponents not the ui:components
• JSP Custom Tags
• From Java5, obsolete to a JSF application.
• Mentioned in passing in Java6 docs.
• Also creates a new tag to be used with xhtml.

In general if you're talking about facelets, a component is a ui:component and a custom tag is a facelets custom tag.  If you're talking about JSF, a component is a UIComponent and a custom tag is a JSP custom tag.

Further more, this shouldn't be confused with general purpose software components, strict components, or modules.

Documenting Facelet Components

Right now I've been trying to figure out how to properly document Facelet includes, Spring Web Flow directories and Facelet components.  It seems that for Facelet components you're to use the JSF Tag Library Descriptors (TLDs).  I've been having a rough time finding how to do TLDs on the web, and could only find the (somewhat dry) entries for the Java EE 5 Tutorial and Java EE 6 Tutorial.

I read all of these docs a few months ago, before "getting my hands dirty" by actually using these technologies on a project.  It looks like time for a re-read.

Facelets, Includes, Templates and Custom Tags

So I've been working with Facelets on a project recently and had to understand the differences and similarities between includes, templates, compositions, custom tags and define/inserts.  Jacob Hookom made a great blog post about this.

An include is self-explanatory, it is as if the included code was right there in the including page.  This applies to all variables and backing beans as well.

A composition lets you compose a section of html with a template and defines/inserts.  More specifically, a composition can use a template for the majority of the structure and then make some defines to "fill in" the specifics of the template.  The define is matched to the corresponding insert (they have the same name attribute).

A custom tag lets you easily reuse a composition.

What I've taken to doing is using a custom tag that has some inserts in it, so I can just use the tag and a few enclosed defines to create what I need.  This lets me keep all conditional JSTL tags (if, choose) away from the custom tag implementation.

All in all, I'm really starting to like it.