Apache MyFaces 1.2 Web Application Development: Building next-generation web applications with JSF and Facelets

Because it is a part of the Apache project, Apache MyFaces and all of its subprojects are available under the terms of the liberal Apache License, Version 2.0. Judging by the list of companies using MyFaces at the MyFaces wiki (http://wiki.apache.org/myfaces/Companies_Using_MyFaces), Apache MyFaces is widely used, worldwide.

The MyFaces project as a whole has an active community of developers all over the world. Many individuals, as well as a number of companies, contribute to the projects. As one of the co-founders of the MyFaces project, the Austrian consulting company, Irian Solutions GmbH, has a large number of employees contributing to the project. The multinational software giant, Oracle Corporation, also has a number of employees contributing mainly to the Trinidad subproject, which was started with a large donation from Oracle.

Good community support for MyFaces and all subprojects is available through the MyFaces user mailing list. Detailed information on this mailing list, as well as a subscription link, can be found at http://myfaces.apache.org/mail-lists.html. It is good manners to start the subject line of any message to the list with the name of the subproject in square brackets such as [Core] or [Tomahawk]. As with most mailing lists, it is worth searching the history to check if your question has been asked already. A good tool to search the mailing list archives is provided by MarkMail, a link to which is provided at the page mentioned earlier.

A lot of application servers are using Sun Microsystems’ JSF Reference Implementation (Sun JSF RI) of the JSF standard, which is also known by its code name, Mojarra. In most cases, it is possible to replace the application server’s default JSF implementation with MyFaces; however, this is almost never necessary. As both the Sun JSF RI and MyFaces core implement the same standard, there should not be much difference between using one or the other. All subprojects of Apache MyFaces should work on both MyFaces Core and Mojarra/Sun JSF RI without any problems.

On the other hand, if your application server uses Sun JSF RI by default, switching to MyFaces might be worth considering, especially during the development stage, as MyFaces Core gives a lot more diagnostic and debug information in the server logs than Mojarra does.

Whatever you choose, it is always useful to know which JSF implementation you are running your application on. When you encounter a strange problem, which could be a bug, one of the first questions on the mailing list will probably be what implementation you are running. An easy way to determine which implementation you are using is to consult the server logs of your application server. During start up, the name and version of the JSF implementation will be written into the log file.

The Apache MyFaces Core project is where it all started. It does not do much more than implement the JSF standard. There are currently three relevant versions of this standard:

The Core project currently has branches for each of these JSF versions. The 1.1 and 1.2 versions are stable and are updated regularly. Work is in progress on the 2.0 version, but a stable release is not yet available, as of the time of writing this book. In this book, we will focus on JSF 1.2. We’ll see that many features defined in the JSF 2.0 standard are already available in JSF 1.2 through one of the many subprojects of MyFaces.

You may have noticed that there is no chapter on the MyFaces Core project in this book. This has to do with the fact that the MyFaces Core project implements only the JSF standard. That means that discussing the Core project in detail would be more or less the same as discussing the JSF standard in detail, and that is beyond the scope of this book. However, some good books on JSF are available, and you can refer to them. Of course, we will discuss specific issues that we will come across when using MyFaces Core as a JSF implementation on our application server. These issues will be discussed in Chapter 2, Getting Started.

Tomahawk has been part of the Apache MyFaces project from the very beginning. Its main goal is to implement a larger set of components than the rather minimal set that is defined in the JSF specification. Tomahawk contains both extended versions of standard JSF components and components that are not defined at all in the standard. Some examples of components that are added by Tomahawk are:

Tomahawk also features some custom validators that make it easy to validate, for instance, credit card numbers and email addresses.

There are two variants of Tomahawk, as follows:

We will take a detailed look at Tomahawk and all of its components in Chapter 4.

The MyFaces project also has a subproject called Sandbox. The Sandbox project is a testing ground for new JSF components that might be added to Tomahawk in the future. Sandbox components are generally "work in progress" and are generally not "feature complete". Sandbox components may or may not be promoted to the main Tomahawk project.

Due to the dynamic character of the project and the uncertain status of its contents, it doesn’t make sense to cover it in a book. However, if you’re looking for a special or advanced component that cannot be found in one of the other component sets, it may be worth looking in the Sandbox. You should realize that it might be harder to get support for Sandbox components, and that there is some uncertainty about their future. On the other hand, you might be able to help to get the component to production quality so that it could be promoted to Tomahawk.

Trinidad is a very extensive set of JSF components. It was developed by Oracle under the name ADF Faces. When Oracle donated this component set to the ADF Faces project, it was renamed to Trinidad. As with the Core project, there are two versions of Trinidad for each version of the JSF standard. Trinidad releases numbered 1.0.x are compatible with JSF 1.1, and releases numbered 1.2.x are compatible with JSF 1.2.

Some of the most important characteristics of Trinidad are:

MyFaces Trinidad will be covered in detail in Chapters 5, 6, and 7.

Tobago is the third set of components that is a part of MyFaces. Tobago was contributed to the MyFaces project by a German company, Atanion GmbH. The emphasis is on separating structure from design. Tobago offers the same concept of extended components as Trinidad does, with one component rendering several elements. It also uses the concept of a layout manager, a little bit like "good old" Swing does. Tobago comes with four different themes that you can choose from. Unfortunately, there is not enough space in this book to cover this third component library.

MyFaces Orchestra is aimed at making it easier to use transactions to persist data in a database. To achieve this, extended scopes are provided, in addition to JSF’s standard application, session, and request scopes. Orchestra is mainly useful in applications where a lot of data is entered into a database with a JSF frontend. Whereas the standard JSF scopes are based on how a web server works, Orchestra focuses on what a lot of applications need, and adds a Conversation Scope, making it easier to keep certain actions within the same Java Persistence API (JPA) transaction, whether they are on the same page or not. Orchestra is based on parts of the Spring 2.0 framework and works with JPA-based persistence layers. Orchestra is covered in Chapter 9 of this book.

Portlet Bridge is one of the newer subprojects of the MyFaces project. It is still in the alpha stage at the time of writing this book. It will be the reference implementation of the JSR 301 standard. The JSR 301 standard is an effort to standardize the way that JSF artifacts (pages or parts of pages) can be used as portlets within a portal environment. Considering the stage of both the JSR 301 standard and the Portlet Bridge subproject, it will not be covered in this book.

The Validator project was recently added under the MyFaces Extensions umbrella project. This project was created as a separate project by its lead developer under a different name, but joined the MyFaces project in December 2008. Although the full name of the project is MyFaces Extensions Validator, it is mostly referred to as ExtVal.

The goal of ExtVal is to eliminate the need to repeat validation code in the View layer of a Java EE application. This is often necessary in order to give user-friendly error messages. However, according to the Don't Repeat Yourself (DRY) principle, repeating code is not desirable. ExtVal uses standard JPA annotations to dynamically create JSF validations. It also adds some extra annotations for cases where a validation cannot be expressed in a JPA annotation. Thus, ExtVal eliminates the need to add validators to JSF pages as well as the need to repeat validation code.

It should be noted that there is a JSR with number 303 that aims to achieve a comparable goal. JSR 303 is called bean validation, and will be part of Java EE 6.0. ExtVal will be compatible with JSR 303 and already goes beyond what is possible with a bare JSR 303 implementation. ExtVal will be discussed in detail in Chapter 10.