Irian

"CDI für Rich Clients" in Eclipse Magazin

2012-05-17T17:56:33Z

The current issue (4.2012) of the german Eclipse Magazin (http://eclipse-magazin.de) includes the article “CDI für Richt Clients” from Jakob Korherr (Software Engineer at IRIAN).

This article explains how it was possible to integrate Apache OpenWebBeans (CDI implementation from Apache) and Apache MyFaces CODI in an existing Eclipse RCP project and how the project benefited from it.

Here is the original blog post from Jakob: http://www.jakobk.com/2012/05/cdi-fuer-rich-clients-in-eclipse-magazin/

Irian@JAX 2012

2012-04-19T10:06:50Z

Irian will be at the JAX 2012 in Mainz. Michael Kurz will do the session JSF 2 Kompositkomponenten im Einsatz on 19th April 2012.

The slides and examples are available for download.

Marrying JSF and Scala Part 3 - Custom Components in Scala

2012-02-29T09:57:30Z

Marrying JSF and Scala part 3: Custom Components in Scala

Introduction

While JSF2.0 has simplified the component building a lot thanks to the
composite components, there are still usecases when the classical component
building tasks have to be performed.

We showed in part 1 and part 2 how to build the basic JSF artifacts in Scala we now are going to dive deeper into JSF by showing how to leverage Scala to build your own jsf custom component.

In this article we combine various techniques of Scala for programming custom components.
The case we are going to investigate is a simple hello world component.

A custom component in Scala

First we have a look at the component itself:

Code a) Custom component

We have a simple component which exposes one additional attribute sayHello2. The component itself is a composite component with an xml template for rendering an performs some listener tasks.

So far so good, however we use several things here which are of interest:

Code b) Singleton

A singleton object for static replacements and struct replacements

Code c) Listeners Array

A listeners array for combining multiple listeners

Code d) trait

a trait instead of a utils class to combine common functionality of components

Code e) Type matches

matches for types to avoid instanceof cascades

Lets dissect the code parts one by one:

1) Object HelloWorld

Scala does have neither static variables nor structs, instead of that it provides singletons as language construct.
Static variables simply can be simulated by a singleton and a simple in class import:

Code b) Singleton

and then

Code f) import

Allows you to import the instance variables and methods as semi native members.

Code g) import usage

2) Annotation Arrays

Code h) annotation array Scala

is simply what would be in Java

Code i) annotation array Java

Since this code transition is not quite obvious even within the Scala documentation, it is worth to be noted in this blog.

3) Traits

The most interesting part is the traits part.
First of all, what is a trait? To sum it up, a trait is an abstract class which can be multiply inherited sort of an interface with code. Now this opens quite a few possibilities:

Common constraints can be isolated and shared among object instances without having to revert to singletons.
Traits can access "this" and can call methods provided by the class as abstract members.

We reuse traits in this case to isolate common component behavior without having to introduce yet another helper class or an abstract base class.

In fact we finally can share this referencing code among components with different base classes without having to introduce our own inheritance hierarchy.

The trait looks like following:

Code j) Trait

We use only a subset of this functionality namely getAttr and setAttr.

Code k) getAttr

Here we can see clearly the this reference to the underlying component getAttributes with

def getAttributes(): java.util.Map[String, AnyRef]

being defined only as interface, which has to be implemented by the component or one of its parents.

4) Match patterns

Now an interesting language part in Scala is the extended matches. Not only you can match in Scala for values, also matches for types and patterns are allowed.
We use the type matches to avoid instanceof if cascades:

Code l) match patterns

The cases basically replace if instanceof constructs here

A renderer in Scala

Now what if we want to write the renderer in Scala.
Scala there can support us as well, it has XML support in the language baked in.
Now lets have a look at the renderer (if not done in an xhtml template like it should be)

Code m) renderer

Now the interesting part of this renderer is following code:

Code m) render part

As we can see, we simply write the html directly constructs like id={id} and {text} allow for inline templating.

There are constraints to this approach

We cannot write out partial xml. The xml written always must be complete, hence we cannot simply write an open tag first, call a subclass and then close the tag
We do not use the startElement, endElement. The plus side is readability.
In the end a composite component and its direct xhtml rendering should always be the first choice. Xhtml simply is the target platform in most cases why not use xhtml also for the component renderer part.

References

JSF Ajax and Multiple Forms

2011-11-26T16:26:23Z

This blog post is about a problem which about 80% of all user problems regarding JSF Ajax in the MyFaces mailinglist revolve around. Namely how do I handle the JSF Ajax in a multiple form scenario.

JSF Ajax and multiple forms, a standard case, which should be easy right?

Let's have a small look at an example:

As we see here, two forms each updating a component in itself via Ajax.

Now what happens if we submit the forms alternating. After a while we run into a ViewRoot cannot be found Exception on the server side.

We did everything right, why do we face this issue?

The answer lies in a bug in the JSF Ajax protocol, more precisely the way the ViewState is processed. Lets have a look at an Ajax response:

Here we see the root cause of the problem. There is a parameter defining the ViewState with the identifier javax.faces.ViewState, however it is not clear where it belongs to.

Practically a ViewState must be attached to a form. So the issuing form definitely must receive it. However what about the other forms? And here is the root cause of the error. Only the issuing form is updated and the ViewState which is dependend on the viewroot not the form in the second form is not updated. This image shows exactly what happens:

As you can see only one form is update the second form now has a ViewState which is not the current one and at one point is dropped from the ViewState history, a classical concurrency issue.

So the solution would be to update all forms in the html document, right?

Theoretically yes, but there is one API which prevents this simple solution: Portlets, in a portlet environment you have multiple ViewRoots all belonging to different JSF session instances on the server. The next logic solution would be to update all JSF elements under ViewRoot.

Again, a good idea, but the protocol prevents it. On the pure client side we do not have any marker or indicator, which tells the Ajax code where the current ViewRoot begins. To ease this protocol problem an extension to the JSF spec was added under 2.1 which eases this problem. According to the spec you have to add the second form manually as render target. Something which both implementations follow.

Here is a snippet which shows the solution:

Here we can see, we have added the second form as render target. Now both forms will be updated and the ViewState always will be up to date. This solution while being spec compliant is not satisfactory.

Sometimes, you dont know if a certain form is still present after the Ajax case. Is there still a way to update all forms in the page or at least to take the form id out of the equation? Unfortunately not within the bounds of the specification.

However, being aware of this issue, I have added in Apache MyFaces additionally to the spec behavior two other ways to resolve the issue. First, you don't have to define the form as render target, but you can define any element within a form as render target and the form will be updated.

Secondly, the probably best solution.

A configuration parameter which forces MyFaces to update all forms in a page. With following code snippet you can enable this mechanism:

Once you have added this snippet of Javascript, MyFaces will be in no portlet mode and will enforce an update all forms with the ViewStates policy.

Note: While this method wont break the code if you switch to Mojarra, you will not get the benefits, because Mojarra does not yet have a similar solution to the issue.

JSF Ajax and Encoding

2011-11-26T16:28:04Z

The entire story started when we got the request to encode everything in ISO-8859-1, including the Ajax cycle. Well first I thought it was easy just change the encoding on the Javascript side, let the server handle the rest.

The encoding was easily detectable on the Javascript side simply by checking the xhtmls encoding (the meta tag head encoding itself would have been another option, but since we are nailed down to xhtml anyway due to facelets we have an easier way)

Easy, I thought, but then I ran into browser hell. The problem normally would be easily resolvable.

The XHR object has the option of adding

xhr header content type:

xhr.setRequestHeader("ContentType", "application/x-www-form-urlencoded; charset=ISO-8859-15");

The problem now are the browsers themselves. By testing the dynamic encoding on various browsers following came out:

*Browser*	*Actual Encoding*
Mozilla 7	UTF-8
Chrome	UTF-8
IE	ISO-8859-15
Opera	ISO-8859-15

So what does this mean, only Opera and IE got it right.

Which means the path of allowing non UTF-8 submits is blocked for now. However JSF automatically deals with the problem properly. While I implemented the most of the Ajax part of MyFaces, I have to admit the actual encoding part was provided by another project, namely j4fry and its implementors worked on that part, so I never gave a second thought.

However both implementations deal the same way with the issue. First Ajax submits are UTF-8 encoded, this at the first look could pose problems with non UTF pages.

It turns out there are none. The solution both implementations follow is to encode the actual key value pair parameters into a utf url encoded representation. Both implementations seem to apply the encodeURIComponent function of Javascript, no matter what content type the page has, always a proper utf-8 representation of the original content will be passed down.

Given the response type also then is UTF-8 what happens with the response. After all the page needs to handle the response properly in its own encoding.

Well there MyFaces and Mojarra differ slightly. Both in compliance with the specification, encode the response in a XML CDATA block. However MyFaces does additional escaping of non ascii chars with their unicode representation, while Mojarra simply pushes the content byte per byte into the CDATA block.

Here is an example:

Mojarra:

Here it is clearly visible that the cdata block has a different encoding than the outer UTF-8 encoded xml. In the final page representation all the special chars are visible again as they should be. However MyFaces goes one step further and escapes the content additionally to get rid of the non utf-8 representation of the characters.

However this comes from the fact that MyFaces basically also does an escape of special chars at a full page refresh, so the core behavior regarding the partial response is the same. So what happens for instance if you just tamper with the UTF header.

You automatically will run into problems due to the uri encoded UTF-8 representation of the parameters. In the worst case you will trigger a server error because of non decodable parameters, in the best case if you pass down ascii only chars you will get it through, in the normal case you will get junk in which is wrongly decoded.

See here an example on IE9 and Mojarra:

The question remains, are both save from a client point of view?

Theoretically it should be since everything is embedded in a CDATA block. However I cannot say if the browsers swallow really everything within their browser engines which is embedded in a CDATA block (aka every byte combination outside of their encoding).

It comes down again to the golden rule #1 in web programming, use UFT-8 and never bother with other encodings, if you can.

Slides and examples for W-JAX 2011

2011-11-24T11:18:53Z

The slides (in german) and examples for both Irian W-JAX 2011 sessions are available.

Go Fullstack: Webanwendungen mit Java EE 6 bauen (Slides|Examples)
JSF and JPA effizient kombinieren (Slides|Examples)

Irian@W-JAX 2011

2011-11-09T10:30:31Z

Irian will be at the W-JAX 2011 in Munich. Michael Kurz will do two sessions: Go Fullstack: Webanwendungen mit Java EE 6 bauen on 8th November 2011 and JSF and JPA effizient kombinieren on 9th November 2011.

Introducing Apache MyFaces Modular Includes

2011-11-08T17:57:53Z

Introduction:

Why modular jsf.js includes, there is one jsf.js file, right?

Since the beginning of the introduction of jsf.js in JSF there has been only one jsf.js file which serves all Ajax needs. However, at least for Apache MyFaces there have been a lot of extensions added such as:

iframe ajax fileupload
html5 form detection
client side i18n message support for various languages (including chinese)
legacy browser support down to blackberry 4.7 and winmobile 6.5 and ie6
browser optimisations for browsers supporting dom level3
queue control for the ajax request queue
timeout handling
better error handling
delay handling
modular structure which can be changed at runtime to replace it with your own implementation of subparts
clear distinction between api and impl on codelevel

(More info on many of those extended features see following Link)

Most of those extensions will make it one way or the other into the official jsf spec. However different scenarii have different needs.

While most legacy mobile browsers are now slowly phased out (and is seen as deprecated) ie6 for the time being is still supported with a burden of legacy code. However in a pure modern mobile environment for instance you need smaller files and no legacy code at all.

Many users are also perfectly happy with a pure implementation of jsf.js according to the spec without any extra features. Other users only need a subset of those features and want to leave out the other (i18n support for instance)

The advantage of dropping code is smaller filesizes, faster code due to less lines which have to be processed, and less fallbacks which have to be prechecked.

Reducing code according to the usecase scenario is something worthwhile to explore, given modern mobile browser environments and situations, where you simply want to be as lean as possible.

So what is the solution for all this?

The MyFaces jsf.js Modular Includes

As of MyFaces 2.1.4 a modular include system will be added. Simply by adding following parameter to your web.xml you will be able to determine what will be included With the parameter org.apache.myfaces.JSF_JS_MODE and the allowed values of

normal
modern
minimal-modern

you will be able to adjust which version of jsf.js is included. If you need extra functionality, you can include the subparts excluded from your version as separate Javascript resources via normal jsf mechanisms. Following image shows the version of each file and the extra functionality:

Modular include parts

As you you can see you can stack and mix all the modules you need by simply choosing a base jsf.js and then you are able to stack the extra functionality needed by adding a separate include. That way you have the choice between filesize, number of includes and features according to your needs.

Example on how to Enable the Modular Includes with Additional Features

The following example will include the minimal-modern jsf.js and will stack all the extra functionality on top of it. web.xml in your page template As you can see all you need to to is to reference the correct js file additionally which is hosted under the resource module myfaces and you are ready to go.

Apache MyFaces Queue Control

2011-11-08T16:44:19Z

Introduction

As some people might have noticed the Apache MyFaces javascripts are bigger than Mojarras. There is a reason for it, besides our internal structures completely different we have a set of extensions which yet have to make it into the official spec (all of it has been donated to the EG) I already wrote about the fileupload via ajax, and again, I have to warn, if you use that stuff you are bound to MyFaces. But nevertheless, partial page submit and queue control are two important features which have been enabled since 2.0.1:

Queue Control, what is it?

The official spec enforces following behavior: if you submit an Ajax post it is either sent directly if no other submit is running or enqueued until the running ajax submit has terminated and then the submit is issued.

Now this causes following problems

The typical fast typing Ajax input.

Here typing happens on the fly and a load of submits are issued, they are either queued or simply sent to the server causing constant loads.

The long running Request

Here a request hangs for a longer period of time, filling the client queue. For those two szenarios we introduced (thanks to the j4fryguys Ganesh and Alax who donated the code), advanced queue control. Here is the deal on how to use it (and again the obligatory you bind yourself to myfaces warning) First a short introduction to our configuration system: We are very modular all layers are bound late via configuration and also vital parts of the system can be replaced without digging into the code internals that way, this configuration system also can be used to override certain default behavior. Now there are to ways to override the configuration, you can do it globally under the myfaces.config namespace or locally by pushing another additional set of parameters in the options map under myfaces (example below) An example for a global configuration for instance is: an example for a local configuration override for a single request is: Now we have following possibilities in our codebase:

timeout: describes a value of miliseconds upon the current request should be terminated for good and the next one be issued

delay: describes a delay period where the system waits for the next input before issuing the submitted. If an input is sent before the delay period is over the old request is canceled upfront and the new one is enqueued delayed.

queuesize: This limits the queue size of the request queue to the specified number of elements, if the queue is bigger than what is provided older elements are dropped until the queue size is fulfilled. If issued locally the reduction is only done temporarily.

For a typical ajax scenario following might be a viable approach:

Second Part, PPS

This solves following scenario, per spec definition the entire form passed down must be submitted at each Ajax scenario. Often this is unnecessary, especially if you only execute parts of the subtree. Unnecessary data is passed down and if you have something like a textfield in the form then it is even heavy on the server. There pps helps. With pps you will just pass what is needed to be executed, you also can put the execute on a parent node and it determines which childs have to be passed down the execution chain and it only submits the parameters it really needs to pass down. (note this does not work in the ajax fileupload case) Here is an example on how to use it: again this also can be set globally via myfaces.config.pps = true

Marrying Scala with Apache MyFaces Part 2

2011-11-08T16:42:07Z

View Controllers and Navigation

While part1 showed us how we can do managed beans in Javascript, we now will go a little bit deeper. In this part we will talk about view controllers and navigation implemented in Scala.

Short Introduction to ViewControllers

While JSF does not know the ViewController pattern, for JSF is everything a managed bean, it makes sense to name a certain set of managed beans ViewControllers. Per definition in JSF a ViewController is a managed bean, which deals directly with the user interface interaction from the backend. Such interactions are

Actions
Events
Listeners
etc...

A typical plain Java Viewcontroller

So a typical Java ViewController in a plain JSF environment looks like following. Everyone who has programmed JSF is familiar with those patterns. Sidenote: there are frameworks which add dedicated view controllers with dedicated callbacks for postCreate, preRender

ViewController in Scala

The question now is, how does this look in Scala. Again, this code is somewhat smaller thanks to the absence of setters and getters. However the structure of this class is not 1:1 translatable to Java due to following new construct: So what is this object all about? Scala does neither know static classes nor variables, instead it has singletons in its language core as companion pattern to classes. If a construct is defined via object instead of class, then the resulting object is a singleton. To make the code tighter, Scala also allows imports everywhere. Members of singletons can be imported simply by import <Singleton>._ so that we can call them directly in our code. If you notice in our action callbacks we return the members of the singleton directly, like we would do it with static variables in Java.

MyFaces Codi Typesave Navigation

MyFaces Codi has an interesting feature, the so called typesave implicit navigation. While JSF2 already eased the lives of developers by introducing an implicit navigation (aka return value of an action == page name if no navigation rule is given), MyFaces Codi goes one step further. It maps pages to classes (page name must be the class name) and it allows the grouping of navigation elements in wrapper classes (follow this link for further reference). While in my personal opinion, the class based navigation alone, it really shines once you add advanced codi features to it like the security handling or the View Controller extensions. (For more Information please consult the MyFaces Codi documentation) Here is a small example: This is a very basic example of two navigation cases

the first one points to /Wizard/Page1
the second one points to /Wizard/Page2

However to map this to scala we face a set of problems

We don't have interfaces, we have mixins, but they do not map straight to the structures we need
the interface classes are the same problem as the interfaces

So we have to find structures which Codi can follow but are buildable in Scala. Here we have the same example in Scala: Again we are able to map everything into singletons so we work with a set of objects instead of interfaces and interface classes.

Marrying Scala with Apache MyFaces

2011-11-08T16:39:30Z

This is the first part of a mulitpart blogpost on how to marry JSF with Scala.

Why Scala? Java is fine

My personal opinion is, having done programs in many languages, that Scala is a huge step up from Java complexity-wise and many things are corner case fillers which probably could have been left out with a more lenient approach. Nevertheless Scala has lots of merits as well. The code reduction compared to Java on the average is 30-50% less thanks to better property handling and other things like closures. The speed if touched right is about the same as Java (one of the complaints about groovy). However, if you want to apply Scala you seriously have to touch it the way you would touch C++, make up your mind on what part of the language you really use and only touch others in rare cases. But lets stop the criticism here. Scala has lots of merits especially for JSF:

Absence of setters and getters
Tight integration with Java
Isolation of common constraints via Mixins instead of base classes
Same or almost the same performance as java
Closures for things like iteration
etc...

So lets dig into JSF and Scala

Part 1, Managed Beans

The possible easiest entry into combining Scala and JSF is to create a managed bean. Every managed bean in JSF is a pojo with a handful of setters and getters. (and more depending on your functionality) It probably is the easiest artifact within the JSF stack you can get. Let us have a look at a simple Java managed bean: The same now would be coded in Scala Note for the people who are familiar with Scala, we took two assumptions here, first we are using for familiarity reasons the Java mutable LinkedList and secondly we use BeanProperties (we could resolve that with our own el resolver as well) This is tightlier written, but what about data encapsulation what about setters and getters? Scala follows a different route for data encapsulation. You can set properties but usually the data is public until you have overrides which cause the data encapsulation without any further code interference. Also one thing noticeable is, that the implements Serializable has been replaced by a @serializable annotation. The rest of the annotations is applied as is.

So what about this @BeanProperty?

This is a special Scala annotation which tells the compiler to encapsulate the property and generate setters and getters for it.

I want to use CDI instead of ManagedBeans

CDI has been the new kid on the block and given that bigger projects nowadays either use Spring or CDI it makes sense to cover the CDI integration here as well. To sum the CDI and Scala situation regarding managed beans, it is as seamless as it is with pure managed beans. Here is an example: Of course you still can use @Inject and other CDI constructs as well.

@BeanProperties is this really needed?

As you have seen @BeanProperties produces the connection between our properties and the EL by encapsulating the property and providing Java like setters and getters. This is very inelegant, first of all, because to access those properties, you have to use the setters and getters on the Scala side as well, and the code is convoluted with annotations. Wouldn't it be nice to simply have something like: This works as expected, even the EL will pick up all properties, thanks to Scalas public per default convention. However we now face a problem, once we want to encapsulate for instance val1. If we now would make it private or protected the code definitely would be broken and the EL would not pick it up anymore. As long as you stay in Scala, you can use Scala properties, however the EL is implemented in Java and expects Java setters and getters. So to make the EL scala aware we have to roll out a binding solution, but first, lets talk about Scala properties. Scala properties are a different convention. From outside they are invisible by default but they still implement full isolation. So, code like myobj.myprop = 1 still would be myobj.myprop = 1 after the isolation has been added. So how do we do it?

the def val1: Int = _val1 is basically our new getter replacing our old val1 for read access
def val1_$eq (val1: Int) is basically a convention to open val1 for write access via the = operator.

This works within Scala seamlessly and for orm frameworks as well as long as they know the Scala convention (most do by now via plugins). But on the Java side you have to call those methods directly via <methodName> and <methodName>_eq. The last remaining open problem is the Expression Language. The EL relies on setters and getters for accessing the properties. Thankfully there is a way to override the ELs handling via a custom resolver tailored for Scala. Now this code would override the scope of this blog, but you can download the sources for this EL resolver here: (note a link to an el resolver drop in project will be added later this month so check regularly) You just have to integrate it into your project by adding following entry into your faces-config:

End of Part1

We now have reached the end of part1. The next part will be about the ViewController patterns. Page navigation Codi style in Scala, and what we can do with Scala traits in a JSF context. So stay tuned.

JSF@Work 1.0.4

2011-11-07T08:50:47Z

IRIAN released version 1.0.4 of the JavaServer Faces (JSF) online documentation "JSF@Work". This version features new content about composite components and converters and contains lots of enhancements and improvements. The tutorial contains a complete list of changes.

JSF@Work is available (currently only in german language) at: http://jsfatwork.irian.at.

www.irian.at relaunched

2011-10-17T10:53:08Z

As you can see www.irian.at has been completly redesigned. The most obvious change is the new look. But the more interesting changes from our point of view are under the hood.

The new site is build on Liferay 6.0 Community Edition. It does bring quite some overhead compared to the old site which was using JSF (the MyFaces implementation of course ;)). However we do believe that the overhead is worth it and pays of once you learn how to use Liferay properly.

The main reason why we chose Liferay was that we wanted a CMS in order to be able to change the content more easily. The content on the old website has not been updated very often. We plan to change that and keep the new site always up to date.

Other nice features that come for free (if you don't count the time spent learning how to configure them correctly) are security and user management, search, advanced styling and templating, the blog engine and internationalization.

Of course we have not given up on JSF. On the contrary! Some portlets on this site - for example the contact form or the training registration - are built using JSF 2.0. We have used this combination of portal server and JSF in the past on http://www.confess.eu and it worked out nicely.

We hope that you like the fresh new look and if you have any comments regarding the new design and functionality please let us know.

SimpleMeet.me

2011-11-04T10:08:21Z

The easiest way to communicate

SimpleMeet.me allows you to easily get in touch with one or more people - no signup or setup required. Just go to http://simplemeet.me, pass your code to your contact and immediately start a chat. Communication made unprecedentedly easy.

Release of MyFaces CODI v1

2011-11-04T10:10:07Z

Apache MyFaces Extensions CDI (aka CODI) provides portable CDI extensions for the Java-Platform (SE and EE). CODI is a modularized and extensible toolbox for CDI based applications.

MyFaces CODI is compatible with JSF 1.2.x and JSF 2.x.

More details are available here.

JSF@Work 1.0.4

2011-11-04T10:11:02Z

Release of MyFaces Extensions Validator

2011-11-04T10:12:29Z

The release contains several improvements, new features and an improved support of JSF 2.0 as well as Bean-Validation (JSR 303).

Compared to the standard integration of BV in JSF 2.0 MyFaces ExtVal 2.0.3 offers more advanced and typesafe features.

Further details are available here.

JSF@Work 1.0.2

2011-11-04T10:24:28Z

IRIAN released version 1.0.2 of the JavaServer Faces (JSF) online documentation "JSF@Work". This version integrates Spring 3.0 and JSR-330 and contains lots of enhancements and improvements. The tutorial features a complete list of changes.

JSF@Work is available (currently only in german language) at: JSF@Work

Release of MyFaces Extensions Validator

2011-11-04T10:25:32Z

he 3rd release of MyFaces ExtVal contains several improvements and new features as well as a new validation module for using Bean-Validation (JSR 303) with JSF 1.x and 2.0.

Compared to the standard integration of BV in JSF 2.0 MyFaces ExtVal 2.0.3 offers more advanced and typesafe features.

Further details are available here.

JSF@Work 1.0.1

2011-11-04T10:27:04Z

IRIAN released version 1.0.1 of the online version of the JavaServerFaces (JSF) documentation "JSF@Work". This version integrates MyFaces 2.0 into the examples and contains lots of minor improvements. The tutorial features a complete list of changes.

JSF@Work is available (currently only in german language) at: JSF@Work