7/12/2014: I've not used JSF since I wrote this post years ago, but I've come to the conclusion that a complicated, abstracted lifecycle is a bad thing for a web framework. Therefore I would not recommend using JSF.
I have been learning JSF 2.0 (Java Server Faces 2.0) over the last few days. I never used the original JSF 1.0 implementation so I was slightly intimidated when I read mostly horrendous reviews regarding it. However, my understanding is that the second implementation is much improved and most of the problems have been corrected. I still have a few reservations about the complexity of the application lifecycle, but hopefully my concerns will diminish as I continue to learn the framework.
JSF is a Java web framework. Defined in greater detail, it is essentially a MVC framework, a GUI controls and handlers framework, and an AJAX framework. It competes with other frameworks like Servlet/JSP, Seam, Spring, Struts, Tapestry, Wicket, etc. (although in some cases two frameworks can be used together collaboratively i.e. JSF+Seam, JSF+Spring, etc). The original version of JSF attempted to collaborate with JSP but it quickly became clear that JSF potential was being burdened by JSP limitations. As a result, newer versions of JSF do not make use of JSP at all! Instead it uses a new technology called Facelets. That's a large paradigm shift for many of us who have been using JSP since we first learned Java web development. The current version of JSF is 2.0. JSF 1.0 had some noteable problems, but JSF 2.0 addresses many of them. JSF 2.0 also adds new features like AJAX support. With JSF 2.0 it is possible to add AJAX support with 100% Java code without writing any JavaScript code!
JSF is an officially supported framework. This may be perceived as an advantage compared to other 3rd party frameworks like Struts. There are many different flavors of JSF: Mojarra (basic Sun/Oracle implementation), MyFaces (basic Apache implementation), IceFaces (extended Sun/Oracle implementation), Tomahawk (extended Apache implementation), RichFaces (extended JBoss implementation), etc. Anyone is free to implement their own version of JSF so long as they adhere to the JSR specification. Following the JSR guidelines guarantees that all implementations will have the same basic functionality and features. However, implementors are allowed to go above and beyond the specification. Therefore, some implementations may have additional functionality and features that is vendor specific and not officially supported. This is both an advantage and a disadvantage. If you use an extended JSF implementation with fuller features and functionality you may eventually suffer from vendor lock-in.
To run JSF 2.0 the minimum requirements are Java 5.0 or greater, and an application server that supports Servlet spec 2.5 or greater. Unfortunately, this is a fairly stiff requirement since it eliminates the majority of older application servers. Supported servers include Tomcat 6+, Glassfish 3+, Weblogic 11+, JBoss 5.2+, etc. Newer versions of J2EE compliant servers like Glassfish, Weblogic, and JBoss will have automatic support for JSF. Since Tomcat is only a servlet container and is not J2EE compliant, you must manually install JSF (include 2 jar files). Although there are many different implementations of JSF created by many different vendors, they should run on any application server as long as the minimum requirements are met regardless of the vendor. So, for example, the RichFaces (JBoss) implementation should work ok on the Tomcat (Apache) application server.
Since JSF 2.0 is relatively new the documentation is still a little sparse. I recommend these tutorials for starting:
http://www.coreservlets.com/JSF-Tutorial/jsf2/
I found these tutorials to be excellent overall, except the AJAX tutorial was a little difficult to follow.