Laliluna Java articles and Tutorials

JPA and Hibernate eBook update

2011-10-15T00:00:00Z

Hi all,

I have updated my Hibernate and JPA eBook. In addition the first two parts of the book are now public available.

You can get the full book and the PDF version on http://www.laliluna.de/shop/

The free parts are available at http://www.laliluna.de/jpa-hibernate-guide/

Best Regards / Viele Grüße

Sebastian Hennebrueder

Communication as Cost Driver in Software Projects

2011-08-06T00:00:00Z

Introduction

Software Projects can be expensive. Having seen so many different software projects during my work as software developer and architect, I believe that the same kind of project can cost 100000 EUR, 500000 EUR or even
5 million EUR. There are many different cost drivers in software projects but in this article, I would like to discuss the Distance of Communication.

The knowledge and experience of parties involved in a software project is very different. There are users, managers, business analysts, technical and non-technical project manager, software architects and developers. Assuming that different types of knowledges and expertise does create communication borders, information has to pass many borders to arrive at the people who do the job.

It is very interesting that the organization of many software projects is very close to the following game description.

Telephone Game

The game is called Chinese Wispers in Britain or Stille Post in Germany.

Many children are sitting in a circle. A child whispers a phrase to its neighbor. The neighbor whispers the phrase to its neighbor and so on until the phrase arrives at the child sitting next to the phrase teller. This child speaks out what it understood.

As the misunderstandings from the whispered phrases accumulate the result can be very funny.

In a software projects the future user of the software speaks to his manager. The manager speaks to the business analyst who puts together the requirements from a professional non-technical perspective.

The business analyst passes the requirements to a technical project managers who formulates technical requirements and task descriptions for the software developer.

The software developer develops what he understood.

Once the software is delivered to the users all parties are sitting together, giggle and have fun seeing how the requirements transformed into a more or less useful piece of software.

Parties Involved in Software Projects

There are a number of parties involved in a software projects.

The future user

The future users of the software. Their daily work is going to be supported by the new software. The users can have difficulties to describe what they need. Those people have a good experience in their job but are most likely not GUI-designer or process analysts. They might even not be aware of the full process but only know the tasks involved in his daily job. It’s like someone who drives a car. He can tell you that a car is good, the steer wheel is well placed but driving a
car does not make him a car designer.

Manager of the user

Manager of these users, who organize their job and the processes. The manager of the user most likely have a clearer view of the process but he might not know how doing the job does exactly look like.

Business Analysts

Business analysts talking to the users and the managers and writing the requirements from a professional non technical perspective. The business analyst has no experience in practical doing the job but has a more distant view. Distance facilitates having an overview but makes it more difficult to see the details. A business analyst may lack knowledge of the subject as well.

Project Manager

Technical project managers transform the requirements into technical requirements and task descriptions. A technical project manager does not really know the details of the users job from first hand experience. At the same time, a project manager might not even know how to do software development. He is responsible for organizing the software project.

Software Developer

Software developers doing the GUI design, coding and technical architecture work. Sometimes the architects are separated from the normal software developers. The software developer has the biggest practical part of creating the software but at the same time the biggest distance to the people knowing how and what the software should solve.

The knowledge, skill and experience of each party is so different that each communication border will lead to additional errors in understanding the requirements.

The Cost of Communication Distance

The cost of a software project can be expressed by the formular:

base * 1.5 ^ (n -1)

base is the basic estimated price. It can only be achieved if the developer is coding something for himself.

n is the distance between the developer and the user. If the developer communicates directly with the user, then n equals 2. For every person in between n increases by one.

The formular is correct until it is proved to be incorrect. At least it is indicative.

Java Persistence and Hibernate eBook updated

2011-05-20T00:00:00Z

What’s new?

Rework of the Component Chapter
- update from CollectionOfElements to ElementCollection (the former is now deprecated)
- better explanation why and when you need to implement equals and hashcode in component collections

Rework of native SQL Chapter
Some times you need to get full access to database specific features. In those cases you need plain SQL.
But did you know that Hibernate can create entities from SQL queries? The chapter has been significantly enlarged and covers SQLResultSetMappings as well.

Query chapter
I have added some examples to query for example authors having two books in their collection. Hibernate provides a number of short cut functions to avoid subquery:
element, size, member of.

Access to JDBC is explained now in detail

Session.lock
session.lock is now deprecated. You will find the new approach session.buildLockRequest in the book.

Cascading
Cascading has slightly changed considering so-called orphan-removal. This is now supported by JPA as well and the Hibernate cascade type is deprecated.

ResultTransformer
If you query an object for example a book and join a collection of chapters, you will find duplicates in the result list. The preferred way to prevent this, is setting a result transformer.
session.createQuery(..).setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY)

There are other result transformer you may use, when writing reporting queries.

—
Best Regards / Viele Grüße

Sebastian Hennebrueder

JBoss Weld transactions with JPA and Hibernate in Java SE

2011-01-12T00:00:00Z

The target

I am using Weld in a plain Java application (alias Java SE). I would like to inject an entity manager and use a @Transactional annotation to mark a method as transactional. A transaction should be
started before the method is executed and commited after the method was called. In addition exceptions should cause a rollback of the transaction.

@ApplicationScoped  
public class PlayerServiceBean {

	@Inject
	private EntityManager em;

	@Transactional
	public void createPlayer(Player player) {
		em.persist(player);
	}
}

The wrong way

I found various discussions but as at the time of writing JBoss Weld is still young, there seems to be no various ideas floating around but no best way.

I found one proposal by the JBoss people. This approach makes use of an extension to initialize the EntityManagerFactory and adds an interceptor which handles the transaction. This approach suffers of a conceptional problem. Have a look at the interceptor.

	@Transactional @Interceptor
	public class EntityTransactionInterceptor {

		private @Inject @Any EntityManager em;

		@AroundInvoke
		public Object aroundInvoke(InvocationContext ic) throws Exception {
			boolean act = !em.getTransaction().isActive();
			if (act) em.getTransaction().begin();
			try {
				Object result = ic.proceed();
				if (act) em.getTransaction().commit();
				return result;
			}
			catch (Exception e) {
				if (act) em.getTransaction().rollback();
				throw e;
			} 
		}
	}

The entity manager is injected as application scoped bean. It cannot be closed by the interceptor which is required in case of an exception. In addition every time we call the method the same entity manager is used and the persistence context will grow. As long as the bean is not removed, the entity manager will not be closed. In case of @ApplicationScoped it will never be closed. We cannot use this bean with two threads as well.

The right way

We need a different entity manager injected per thread and if the interceptor rolls back a transaction, it needs to be able to replace the entity manager in a bean. Either we need to create a custom scope which causes injection every time a method is called on the bean or we need to fake an entity manager which delegates to the current managed entity manager of the interceptor. I am not sure if the first approach works and I am not a weld expert either. Therefor I used the latter approach.

Steps to go

Create a transaction annotation
Create a store which holds the current entity manager
Create an interceptor
Create a fake entity manager which can be injected and fetched the current entity manager from the store

Create a transaction annotation

An annotation is pretty simple to write. Here is the complete source code. The @InterceptorBinding tells Weld that this annotation can be used with an interceptor.

package de.laliluna.transactions;

import javax.interceptor.InterceptorBinding;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Target({ElementType.METHOD, ElementType.TYPE})
@InterceptorBinding
@Retention(RetentionPolicy.RUNTIME)
public @interface Transactional {
}

Create a entity manager store

We define an interface in case we want to change our implementation later on.

package de.laliluna.transactions;

import javax.persistence.EntityManager;

/**
 * @author Sebastian Hennebrueder
 */
public interface EntityManagerStore {
	/**
	 * Looks for the current entity manager and returns it. If no entity manager
	 * was found, this method logs a warn message and returns null. This will cause a NullPointerException in most
	 * cases and will cause a stack trace starting from your service method.
	 *
	 * @return the currently used entity manager or {@code null} if none was found
	 */
	EntityManager get();

	/**
	 * Creates an entity manager and stores it in a stack. The use of a stack allows to implement
	 * transaction with a 'requires new' behaviour.
	 *
	 * @return the created entity manager
	 */
	EntityManager createAndRegister();

	/**
	 * Removes an entity manager from the thread local stack. It needs to be created using the
	 * {@link #createAndRegister()} method.
	 *
	 * @param entityManager - the entity manager to remove
	 * @throws IllegalStateException in case the entity manager was not found on the stack
	 */
	void unregister(EntityManager entityManager);
}

And here is the implementation. The entity manager store stores the entity manager in a thread local. In addition it is responsible to initialize the EntityManagerFactory.
This is a simple implementation. If we want to support multiple EntityManagerFactories we might need to refactor this class.

package de.laliluna.transactions;

import org.jboss.weld.environment.se.events.ContainerInitialized;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import javax.enterprise.context.ApplicationScoped;
import javax.enterprise.event.Observes;
import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;
import java.util.Stack;

/**
 * A store for entity managers. It is basically a ThreadLocal which stores the entity manager.
 * The {@link de.laliluna.transactions.TransactionInterceptor} is expected to register entity manager. The application code
 * can get the current entity manager either by injecting the store or the {@link EntityManagerDelegate}.
 *
 * @author Sebastian Hennebrueder
 */
@ApplicationScoped
public class EntityManagerStoreImpl implements EntityManagerStore {

	final Logger logger = LoggerFactory.getLogger(EntityManagerStoreImpl.class);

	private EntityManagerFactory emf;

	private ThreadLocal<Stack<EntityManager>> emStackThreadLocal = new ThreadLocal<Stack<EntityManager>>();

	public void init(@Observes ContainerInitialized containerInitialized) {
		emf = Persistence.createEntityManagerFactory("samplePU");
	}

	@Override
	public EntityManager get() {
		logger.debug("Getting the current entity manager");
		final Stack<EntityManager> entityManagerStack = emStackThreadLocal.get();
		if (entityManagerStack == null || entityManagerStack.isEmpty()) {
			/* if nothing is found, we return null to cause a NullPointer exception in the business code.
			This leeds to a nicer stack trace starting with client code.
			 */

			logger.warn("No entity manager was found. Did you forget to mark your method " +
					"as transactional?");

			return null;
		} else
			return entityManagerStack.peek();
	}

	/**
	 * Creates an entity manager and stores it in a stack. The use of a stack allows to implement
	 * transaction with a 'requires new' behaviour.
	 *
	 * @return the created entity manager
	 */
	@Override
	public EntityManager createAndRegister() {
		logger.debug("Creating and registering an entity manager");
		Stack<EntityManager> entityManagerStack = emStackThreadLocal.get();
		if (entityManagerStack == null) {
			entityManagerStack = new Stack<EntityManager>();
			emStackThreadLocal.set(entityManagerStack);
		}

		final EntityManager entityManager = emf.createEntityManager();
		entityManagerStack.push(entityManager);
		return entityManager;
	}

	/**
	 * Removes an entity manager from the thread local stack. It needs to be created using the
	 * {@link #createAndRegister()} method.
	 *
	 * @param entityManager - the entity manager to remove
	 * @throws IllegalStateException in case the entity manager was not found on the stack
	 */
	@Override
	public void unregister(EntityManager entityManager) {
		logger.debug("Unregistering an entity manager");
		final Stack<EntityManager> entityManagerStack = emStackThreadLocal.get();
		if (entityManagerStack == null || entityManagerStack.isEmpty())
			throw new IllegalStateException("Removing of entity manager failed. Your entity manager was not found.");

		if (entityManagerStack.peek() != entityManager)
			throw new IllegalStateException("Removing of entity manager failed. Your entity manager was not found.");
		entityManagerStack.pop();
	}
}

Create an interceptor

Now, we can create a transaction interceptor. It will start a transaction before a transactional method is called and commit it after the method was executed.
In addition it will register an entity manager in the EntityManagerStore and unregister it afterwards. Finally, it will roll back transactions in case of an exception.

The annotations @Interceptor and @Transactional tell Weld that every time it finds a @Transactional annotation it needs to call the interceptor.

package de.laliluna.transactions;

import org.hibernate.HibernateException;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import javax.inject.Inject;
import javax.interceptor.AroundInvoke;
import javax.interceptor.Interceptor;
import javax.interceptor.InvocationContext;
import javax.persistence.EntityManager;

/**
 * A simple transaction interceptor which registers an entity mangager in a ThreadLocal and unregisters after the
 * method was called.
 * It does not support any kind of context propagation. If a transactional method calls another's bean transactional
 * method a new entity manager is created and added to the stack.
 *
 * @author Sebastian Hennebrueder
 */
@Interceptor
@Transactional
public class TransactionInterceptor {

	@Inject
	private EntityManagerStoreImpl entityManagerStore;

	private Logger logger = LoggerFactory.getLogger(TransactionInterceptor.class);

	@AroundInvoke
	public Object runInTransaction(InvocationContext invocationContext) throws Exception {

		EntityManager em = entityManagerStore.createAndRegister();

		Object result = null;
		try {
			em.getTransaction().begin();

			result = invocationContext.proceed();

			em.getTransaction().commit();

		} catch (Exception e) {
			try {
				if (em.getTransaction().isActive()) {
					em.getTransaction().rollback();
					logger.debug("Rolled back transaction");
				}
			} catch (HibernateException e1) {
				logger.warn("Rollback of transaction failed -> " + e1);
			}
			throw e;
		} finally {
			if (em != null) {
				entityManagerStore.unregister(em);
				em.close();
			}
		}


		return result;
	}
}

Don’t forget to add your interceptor to the META-INF/beans.xml

<beans xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
	<interceptors>
		<class>de.laliluna.transactions.TransactionInterceptor</class>
	</interceptors>
</beans>

This implementation will cause a separate entity manager for every transactional method. If you are aware of EJB3 or Spring transactions, then you will probably know the transaction type requires_new.
It is the same approach. If you want to achieve context propagation as in a EJB3, we need to improve our implementation. I leave the task to you but will outline the required steps.

Add an attribute to the @Transactional annotation which defines if the method should reuse an existing transaction.
Improve the interceptor
- Check if the @Transactional annotation defines the reuse of an existing transaction
- If an existing TX should be reused, it could check if the store has already a current entity manager. We could add a service method to the store like boolean hasEntitymanager()
- If an existing TX should be reused and an entity manager exists already, do nothing else handle the transaction and create an entity manager.

Create a fake entity manager

The fake entity manager is not the real instance of the entity manager but it is a delegate. It will fetch the current entity manager from the EntityManagerStore and will delegate to this entity manager.

Don’t forget that your IDE can generate delegate methods. Don’t write the code!

package de.laliluna.transactions;

import javax.enterprise.context.ApplicationScoped;
import javax.inject.Inject;
import javax.persistence.*;
import javax.persistence.criteria.CriteriaBuilder;
import javax.persistence.criteria.CriteriaQuery;
import javax.persistence.metamodel.Metamodel;
import java.util.Map;

/**
 * @author Sebastian Hennebrueder
 */
@ApplicationScoped
public class EntityManagerDelegate implements EntityManager{

	@Inject
	private EntityManagerStore entityManagerStore;

	public void persist(Object entity) {
		entityManagerStore.get().persist(entity);
	}

	public <T> T merge(T entity) {
		return entityManagerStore.get().merge(entity);
	}

	public void remove(Object entity) {
		entityManagerStore.get().remove(entity);
	}

	public <T> T find(Class<T> entityClass, Object primaryKey) {
		return entityManagerStore.get().find(entityClass, primaryKey);
	}

	public <T> T find(Class<T> entityClass, Object primaryKey, Map<String, Object> properties) {
		return entityManagerStore.get().find(entityClass, primaryKey, properties);
	}

	public <T> T find(Class<T> entityClass, Object primaryKey, LockModeType lockMode) {
		return entityManagerStore.get().find(entityClass, primaryKey, lockMode);
	}

	public <T> T find(Class<T> entityClass, Object primaryKey, LockModeType lockMode, Map<String, Object> properties) {
		return entityManagerStore.get().find(entityClass, primaryKey, lockMode, properties);
	}

	public <T> T getReference(Class<T> entityClass, Object primaryKey) {
		return entityManagerStore.get().getReference(entityClass, primaryKey);
	}

	public void flush() {
		entityManagerStore.get().flush();
	}

	public void setFlushMode(FlushModeType flushMode) {
		entityManagerStore.get().setFlushMode(flushMode);
	}

	public FlushModeType getFlushMode() {
		return entityManagerStore.get().getFlushMode();
	}

	public void lock(Object entity, LockModeType lockMode) {
		entityManagerStore.get().lock(entity, lockMode);
	}

	public void lock(Object entity, LockModeType lockMode, Map<String, Object> properties) {
		entityManagerStore.get().lock(entity, lockMode, properties);
	}

	public void refresh(Object entity) {
		entityManagerStore.get().refresh(entity);
	}

	public void refresh(Object entity, Map<String, Object> properties) {
		entityManagerStore.get().refresh(entity, properties);
	}

	public void refresh(Object entity, LockModeType lockMode) {
		entityManagerStore.get().refresh(entity, lockMode);
	}

	public void refresh(Object entity, LockModeType lockMode, Map<String, Object> properties) {
		entityManagerStore.get().refresh(entity, lockMode, properties);
	}

	public void clear() {
		entityManagerStore.get().clear();
	}

	public void detach(Object entity) {
		entityManagerStore.get().detach(entity);
	}

	public boolean contains(Object entity) {
		return entityManagerStore.get().contains(entity);
	}

	public LockModeType getLockMode(Object entity) {
		return entityManagerStore.get().getLockMode(entity);
	}

	public void setProperty(String propertyName, Object value) {
		entityManagerStore.get().setProperty(propertyName, value);
	}

	public Map<String, Object> getProperties() {
		return entityManagerStore.get().getProperties();
	}

	public Query createQuery(String qlString) {
		return entityManagerStore.get().createQuery(qlString);
	}

	public <T> TypedQuery<T> createQuery(CriteriaQuery<T> criteriaQuery) {
		return entityManagerStore.get().createQuery(criteriaQuery);
	}

	public <T> TypedQuery<T> createQuery(String qlString, Class<T> resultClass) {
		return entityManagerStore.get().createQuery(qlString, resultClass);
	}

	public Query createNamedQuery(String name) {
		return entityManagerStore.get().createNamedQuery(name);
	}

	public <T> TypedQuery<T> createNamedQuery(String name, Class<T> resultClass) {
		return entityManagerStore.get().createNamedQuery(name, resultClass);
	}

	public Query createNativeQuery(String sqlString) {
		return entityManagerStore.get().createNativeQuery(sqlString);
	}

	public Query createNativeQuery(String sqlString, Class resultClass) {
		return entityManagerStore.get().createNativeQuery(sqlString, resultClass);
	}

	public Query createNativeQuery(String sqlString, String resultSetMapping) {
		return entityManagerStore.get().createNativeQuery(sqlString, resultSetMapping);
	}

	public void joinTransaction() {
		entityManagerStore.get().joinTransaction();
	}

	public <T> T unwrap(Class<T> cls) {
		return entityManagerStore.get().unwrap(cls);
	}

	public Object getDelegate() {
		return entityManagerStore.get().getDelegate();
	}

	public void close() {
		entityManagerStore.get().close();
	}

	public boolean isOpen() {
		return entityManagerStore.get().isOpen();
	}

	public EntityTransaction getTransaction() {
		return entityManagerStore.get().getTransaction();
	}

	public EntityManagerFactory getEntityManagerFactory() {
		return entityManagerStore.get().getEntityManagerFactory();
	}

	public CriteriaBuilder getCriteriaBuilder() {
		return entityManagerStore.get().getCriteriaBuilder();
	}

	public Metamodel getMetamodel() {
		return entityManagerStore.get().getMetamodel();
	}
}

Using your implementation

Here is a simple service.

package de.laliluna.beans;

import de.laliluna.transactions.Transactional;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import javax.inject.Inject;
import javax.persistence.EntityManager;

public class PlayerServiceBean {

	@Inject
	private EntityManager em;

	@Transactional
	public void createPlayer(Player player) {
		em.persist(player);
	}
}

public static void main(String[] args) {		
	// start up the container
	WeldContainer weldContainer = new Weld().initialize();
	// fire an event to cause the entity manager factory initialize itself
	weldContainer.event().select(ContainerInitialized.class).fire(new ContainerInitialized());
    
	// get your bean
	PlayerServiceBean playerServiceBean = weldContainer.instance().select(PlayerServiceBean.class).get();
	
	playerServiceBean.createPlayer(new Player("Sean"));
}

Final words

I hope you have enjoyed the article.

Best Regards / Viele Grüße

Sebastian Hennebrueder

JSF 2 can finally be used in cluster environments

2010-08-23T00:00:00Z

During my evaluation of JSF 2 I mentioned in a mailing list
post that the implementation of the flash scope doesn’t allow to use it in cluster environments.
If you used JSF 2 in a cluster and did use the flash scope then the application behaviour was unpredictable in the case of fail over.

I just came back to review this and other issues and found that the clustering problem is solved. Since version 2.0.3 of Mojarra JSF you can define where the flash scope is saved.

Just make sure to not store it in application scope but to enable the parameter STORE_FLASH_IN_SESSION_SCOPE.

Reference:

Best Regards / Viele Grüße

Sebastian Hennebrueder

Imagine the web improves on 11.11.11

2010-07-15T00:00:00Z

Introduction

This article is a wild collection of ideas around browser and web standards. It is most likely naive and erroneus and there is a fair chance that I overlook existing facts which are already discussed by other people.
But hopefully it provides some new ideas as well and is an inspiration for other people.

I have been reasoning about the problems of

CSS compatibility
Privacy and security impact of social networks and modern web technologies
How software developers could be motivated to build a more secure web following well established standards
How users could be motivated to use and to ask for a more secure web
How we can switch the web into secure mode without breaking backwards compatibility

CSS compatibility

A Cascading Style Sheet (CSS) describes the look and feel of a web page. Some browsers do support only older version of CSS, some browser versions support CSS incorrectly, some browser supports only some features
of a newer CSS version but not all. In addition browsers add non standard features as innovation happens to be faster than updating standards.

All of these facts transforms building websites into a complex task, which requires a lot of browser specific knowledge and limits the use of new CSS features. The worst of all,
there is no stable and clean way to determine the support of CSS across all browsers. As a consequence adaption of new CSS standards is very slow.

Long term considerations

Today so called ‘browser hacks’ allows to define browser specific CSS rules inside of a single file.

If we assume that it is the year 2040. We have HTML version 1 to 15 and CSS version 1 to 22. In addition to the current browsers like Firefox, Internet Explorer, Google Chrome, Safari and Opera, there might be new browsers vendors for special devices.

Do you think that it is possible to write browser specific CSS for the unique combination of CSS version, browser vendors and version using browser hacks? Even today most web developers can not explain by heart all differences of CSS support in the current 5 most popular browsers.

On the long term the only option is to follow standards and to be able to define CSS specific to a standard level. In addition to be able to cope with upcoming versions of CSS there needs to be a way to prevent browsers from
interpreting CSS which they do not understand. This is the reason why we need ‘if conditions’ in the CSS.

Here is an example of an CSS, if if-conditions existed:

if (css.version < 3){
 #main{
	-foo-style: someValue;
 }
}
else if (css.version >= 3	&& css.version < 5){
	-bar-style: someValue;
 #main{
	-foo-style: someValue;
 }	
}	
else if (css.version >= 5) {
 #main{
	-foo-style: someValue;
	-bazz-style: someValue;
 }
}

Conditions based on standard support is a good thing but we don’t live in a perfect world. There will always be browser specific errors. Therefor it is great to
be able to check for browser type and version as well. There had been already proposal to allow browser conditions in CSS and I think that in combination with conditions checking for the CSS version, it is a good thing.

Here is a CSS example checking for browser version.



if (browser.name = ‘FooBrowser’ && browser.version > 5){

 #main{

	-foo-style: someValue;

	-bazz-style: someValue;

 }

}

Why not specifying the css version in header?

Alternatively to if-conditions we could consider a CSS header like the DOCTYPE declaration in an HTML file.

Possible CSS header:



<!DOCTYPE CSS PUBLIC “-//W3C//DTD CSS 2.1//EN” “http://www.w3.org/TR/css3.dtd”>

An argument against this idea is that HTML elements have not changed much over time but CSS changed a lot in short time. If you wanted to support different browsers, you would need to
provide multiple CSS versions for the same document. In addition you are still not able to adapt a CSS for a specific browser. But this is required, if a browser does not support a CSS rule.

Is Microsofts approach of different modes required?

The X-UA-Compatible meta tag is a fix to problem of Microsoft browser. IE-6 was not standard complient. As Microsoft changed its strategy to follow standards, there was
a conflict of web pages which no longer rendered properly in IE-7 or IE-8. This problem is fixed with X-UA-Compatible as it allows web pages to be rendered in IE-8 as if it was a IE-6 browser.

But as already stated, adding the browser type and version as criteria to dermine how a CSS is rendered, increases the number of combinations for which you have to create and test your CSS and web pages. I don’t think that
this is a proper solution on the long term.

Degration of Privacy and Security

The CSS history leak is a well known security problem in browsers. As visited links can have a different style than non visited links, a website can easily determine which pages you have visited. Firefox decided to fix
this problem with an upcoming version. Apple fixed this problem for version 4.1 and 5 of the Safari browser but Microsoft, Opera and Google Chrome are still facing this security problem.

Why is this a security problem?

The answer is simple: The usage of internet has changed. People make use of social networks and publish their names and sometimes even private information on the web. If you can track the pages a users has visited on one of the large social
networking websites, you have a good chance to find out who the person is. Imagine you can find out who a visitor is, for which company he is working and in addition that he has been visiting web pages for people with drug problems.

My personal fear is that social hacking could evolve to one of the largest problem in the internet. While cracking and viruses destroy or steal information and possible money, social hacking could lead to blackmail and distruction of people.

Browser vendors should take the greatest effort to prevent such horror szenarios.

Reference

Private browsing

Private browsing is a concept that opens a browser window or tabulator which is technically separated from all other windows. Once you close that window, all information like history, cookies etc are deleted. While the idea is good and already included in modern browsers,
the browser vendors took care to hide the information in menus and each browser established a different solution how the private browsing behaves and looks like.

Firefox 3.6 provides a menu item ‘Start private browser’ which hides the existing page and starts a blanc page in the same windows.
The private mode is indicated in the title bar of the browser. You can disable private browsing using the menu item ‘Stop Private Browsing’.
You cannot mix browser tabs in private and normal mode.

Microsoft Internet Explorer 8 has a new ‘Security’ menu. The menu item ‘In private browsing’ opens a new browser window. The status is indicated in the title bar of the menu and next to the address input field. You have to close it to delete private information. You cannot mix browser tabs in private and normal mode.

Google Chrome 5 provides a menu item ‘New incognito window’ and opens a new window. The mode is indicated by an image of person, which I would describe as
shadow of a spy in the top right of the browser. You need to close the window to stop private browsing.
You cannot mix browser tabs in private and normal mode.

Safari 4 provides a menu item in a different menu area to enable and disable private browsing. The current status is not indicated in the browser but you need to open the menu.
You cannot mix browser tabs in private and normal mode.

Opera 10.6 provides a menu item to open a new private window tabulator. The status is indicated with a tiny lock. You need to close the tab to delete the private information. You are allowed to have private and non private tabs in the same window.

The five major browsers have five different solutions. None of the browsers makes the option to toggle private browsing instantly viewable. The user must be aware of the possibility and need to find out which menu includes the command.

In my opinion, if we want to convince non technical people to be aware of and to use private browsing, there should be a common approach.

Here are some ideas:

The most important: Not the private mode but the non private mode must be indicated to the user. Without knowing about private browsing and just by using his browser the user learns that there is something like private browsing.

It is a good idea to have a single menu for security and privacy related items (IE-8)

Opening a new browser window is an annoyance and not required. A new tab is much more comfortable (Opera)

The private tabs should be marked clearly and exactly the same way across all browsers.

Could’nt the browser vendors speak at least about security related stuff?

Trigger the private mode from the website itself.

In addition, I think that private browsing could be triggered by the website as well. Imagine a bank or an internet shop can set a flag to trigger private browsing. Once you left the banking website or the paying area of the Internet shop the private information are deleted.

Getting rid of quirks mode

A browser can interpret a website in two modes: standard mode and quirks mode. Standard mode expects the web page to be properly written. The quirks mode of the browser tries to render the page somehow and interprets all trash.

Quirks mode is an extremely hacker friendly way, as it facilitates code injections. Internet users should be able to see if a website runs in standard mode (may be better called quality mode) or in quirks mode.

Motivating to build and to use a more secure web

There are billion of Internet users. How can we make them upgrade their browsers? There are billions of weg pages. How can we make them conforming to standards or even update to HTML 5? As a simple matter of fact,
we cannot change them on a single day and in fact there is no need to update all web pages but to fix broken pages.

What we could do is to provide a big motivation for people to update their browsers and for web site owners to update their sites.

I believe that the most important step is to make users aware of the quality of a website and if they are in a more secure mode or not. Imagine the following icons on the top of the browser:

HTML 5 page in private mode with SSL connection

The first icon indicates the HTML version. It is a cool modern HTML 5 website in strict mode. The second icon indicates if private browsing is enabled or not. In this sample it is activated.

The last item indicates if the connection is using SSL.

Here an example for a HTML 4 page in non strict mode (transitional) in non private mode but with SSL connection.

A second idea to make transitions more popular is to define a common date for a common release of all browsers. Imagine all browsers announce to fully support HTML 5 and CSS 3 by a given date.

Imagine the day of 11.11.11

Best Regards / Viele Grüße

Sebastian Hennebrueder

Hibernate Training Update

2010-04-20T00:00:00Z

In order to provide you with a high quality Hibernate training, the content was updated to include
the brand new additions in Hibernate 3.5

You will learn about all the new mapping options and new API features.

In addition, the cool fetch profile approach is now part of the
performance tuning section.

Best Regards / Viele Grüße

Sebastian Hennebrueder

Blogging like a developer

2010-02-24T00:00:00Z

Blogging like a developer

I write a lot of articles, I have normal pages illustrating my service and training offers, articles and blog entries. Even worse, I want to provide the core pages in English and German language. The nice thing is that I found a flexible and efficient solution to manage this.

In this article, I will explain why Jekyll is the perfect tool for software developers.

 <i>Some italic in pre</i>

package de.gad.gfw.web.graph.model;

/**
 * Created User: xgxthen Date: 16.03.2010
 */
public interface Connection<N extends Node> {
    String getLabel();
    N getSource();
    N getTarget();
}

Old tools

Before, I have used a content management system which was build with php and mysql. I added a blog using Pebble as Java based blogging engine. Most of my articles are
written in Open Office.

Publishing a technical article required the following process.

Create a new page in the content management system
Copy Open Office document and paste it into the CMS (web based)
Clean the HTML
Upload images and fix image links
Upload PDF of the document (I always provide the articles as PDF as well)

My intention was to minimize the effort.

What is Jekyll

It is a blog aware static site generator. This means that it takes a raw-document and apply a template to it to generate a static HTML page.

Blog aware means that it supports things like categories, tags etc.

Jekyll is written in Ruby and supports Markdown, Textile and plain HTML as format. Markdown and Textile resemble WIKI syntax. You may include HTML inside of
those files which is pretty nice.

In addition Jekyll can use pygmentize to highlight nearly any kind of source code.

Home page of Jekyll

Cool process of writing stuff

In the Old Tools paragraph I had a number of steps to publish an article. I shrinked those steps three tiny steps, which are just quick shell commands.

git add *
git commit -a
git push

As Jekyll is file based, you can put all the files into a Git or Subversion repository. When adding an article, I just add it to the repository, commit the changes and
push them to the server. If you use SVN then the commit will automatically include the push to the server.

On the server there is a hook which executes a script to generate the website. I don’t think that there is a faster way for a software developer to blog or to publish articles.

Why Jekyll?

First I considered Pebble as unique tool for the pages. Pebble is a very nice blogging engine, which I used for a couple of years now. It is incredible stable and works like a charm.

There are a number of reasons why I switched to Jekyll.

I am always interested in new technologies.
Jekyll is Ruby based and simpler to adapt to my needs than a Java solution. I am both a Java developer and a Ruby developer. Ruby is incredible efficient for small tools.
Jekyll supported normal pages (not blog entries) in a better way then Pebble does
Jekyll supports different formats to write blog entries. I currently prefer Textile but you may use Markdown as well or just plain HTML.

Links

A page which encouraged me to try Jekyll

Best Regards / Viele Grüße

Sebastian Hennebrueder

Window Id - Practical use cases

2010-01-17T23:00:00Z

Window id – Practical use cases

This post is part of the window id concept series

The concept of a window id.

The window id is sent as request header by the browser and let you identify the window which sent a request.

Request Header
-—————-
X-Window-Id: 279078917624897

Having this window id, we can store data for a specific window in the user session.
The great advantage of such an id is that we can build more stable multi window web application. In this article, I will describe a number of practical use cases.

Until the id is included in browsers, we can enhance the browsers using a plugin. I build a plugin for Firefox but could provide one for other browsers as well.

I have described the concept in Mai 2009 in an article in this blog.

Use cases

Current menu

Imagine you have a menu to navigate in your web application which allows to open a menu group and select a page to navigate to. It could look like the following sample of JQuery UI or the one of JSF Richfaces.

If the user press ‘Reload page’ or submits data, you won’t to show the menu groups opened which were opened before as well. As a consequence, you need to store the information somehow.
How do you achieve this?

One approach could be to save the information in the page template and open the appropriate menu group.

<meta name="xOpenMenu" content="foo">

+ is simple and works with current browsers
- doesn’t work with multiple open menus. Think of applications like Photoshop or Gimp with a number of menus which can be opened to work with layers, colours, …

We could store the information in the users session.
+ is simple and works with current browsers
- does not work if you want to use the application with multiple windows
Best solution

This is a great use case for the windows id concept. If the browser sends the window id with every request, then you can store the information, which menus are open, per browser window in the user session.
Help needed
If you went to get this into browser, then you can help achieving this.

Comment on this and show practical use cases in your own blog.
Vote for Firefox bug Vote for bug https://bugzilla.mozilla.org/show_bug.cgi?id=495395.
Add a ‘+1’ to the mailing list thread of Webkit (Safari/Google Chrome) on mailing list topic  [webkit-dev] Browser issue with multiple tabulators.
Contact Opera/Microsoft

Best Regards / Viele Grüße

Sebastian Hennebrueder

GWT tip - better exception logging on the server

2009-12-18T00:00:00Z

GWT tip – better exception logging on the server

The GWT servlet is not very helpful considering exceptions of the server code. A nested exception gets hidden from the user. This can easily be improved by overriding the process method in a GWT servlet.


public class FooServiceImpl extends RemoteServiceServlet implements FooService {

	final Logger logger = LoggerFactory.getLogger(StockServiceImpl.class);

// ...
 @Override
 public String processCall(String payload) throws SerializationException {
   try {
    return super.processCall(payload);
   } catch (RuntimeException e) {
    logger.warn("Service Layer threw exception: ", e);
    // normally bad style but we need to throw again to inform the client
    throw e;
   }
 }
}

Best Regards

Sebastian Hennebrueder

Oh JavaFX, Oh JavaFX - why don't you progress?

2009-12-01T00:00:00Z

Oh JavaFX, Oh JavaFX – why don’t you progress?
In my article on web
frameworks and technologies I named JavaFX as a coming technology
for plugin based single page application. A year and two conferences
later (JavaOne 2009 and Devoxx 2009) I have to admit that I might be
wrong.

On the Devoxx conference, I held a presentation on choosing web
technologies, had a lot of discussions with other developers about
their point of view on multi page versus single page application and
technologies like Wicket, Tapestry, Grails, Google GWT, JavaFX and
Adobe Air. I saw a presentation on JavaFX and joined the BOF and I
need to say that I am strongly disappointed of the progress of
JavaFX. The presentation was about enterprise development with JavaFX
and mostly showed new components like grids, calendars, trees etc and
how to test JavaFX. It didn’t show anything else not because the
presentation was bad, it was nicely done, but there is nothing else
to show.

Hey folks, enterprise development is not or not only about
components. Enterprise development is about how to build large scale
applications efficiently. May be I misunderstood the intention of
JavaFX and it is mostly meant to build a small app with spinning,
bouncing and twisting elements on the page. But if I didn’t
misunderstand the intention, then I would like to make you aware of a
number of things required to build large scale applications with a
single page technology.

Building dialogs efficiently

A couple of years ago, we switched to web based applications as
they simplified deployment and scalability. In addition building
dialogs was far easier as compared to well made desktop applications.
You might remember the effort building and testing a desktop dialog
with all the drag and drop and context menus.

Building multi page application is extremely fast. Think of
Tapestry using a single tag to render a form with JavaScript input
validation from a given model class.

&lt;t:beaneditForm source="myModel"&lt;/&gt;

Single page web applications are like desktop applications and
naturally share their complexities when building dialogs. It is very
crucial that this can be done efficiently. The user needs to build a
dialog consisting of standard components and his own components as
efficient as possible. He is likely to need the following items

Component pallet of standard and his own components
Working preview
Visual development

Personally, I believe that the Netbeans people are the greatest
JavaFX haters in the world. There is not a great difference between a
text editor and Netbeans when working with JavaFX. Drag and drop can
destroy your code easily and you do formatting the old way using your
tab key. It is just unbelievable.

Common requirements building applications

In my article on web frameworks, I named a number of common
requirements. Most of them apply to single page technologies as well.
I would like to list the most important here.

Input validation

I need to do input validation and I don’t want to do it multiple
times. Having a model like the following class, should allow me to
bind domain fields to components and provide the input validation out
of the box.

@Entity
public class Author {	

	@Id
	@GeneratedValue(strategy = GenerationType.SEQUENCE)
	private Integer id;
	
	@Length(min = 3, max=30)
	private String name;
	
	@Email
	private String email;
...
}

Integration of business layer

Building interactive web application with single page technologies
doesn’t naturally mean that we are switching back to fat desktop
client. Business logic might to a larger extent stay on the server.
Actually all kinds of distribution of logic between client and server
is possible.

Documentation on building normal business applications is
extremely rare to non existing on
http://www.javafx.com/learn/directory.jsp

On the other hand the documentation on spinning and bouncing is
very complete.

More than one dialog

Aren’t there JavaFX applications with more than a single dialog.
Well there are, but where is the documentation. How do I organize
dialogs in a larger application?

Modularization

How do I build a JavaFX application with 100 dialogs efficiently?
Currently, I would recommend to switch to Google Web Toolkit or to
multipage web frameworks. JavaFX needs to address

modularization
develop efficiently with large applications (reloading, starting of modules only)
testing large applications

I cannot wait 30 seconds for my application to start up click
through a dialog and see if a button is now correctly positioned

Testing

The word ‘test’ doesn’t appear on
http://www.javafx.com/learn/directory.jsp
I assume that is because you don’t make mistakes with JavaFX.

Browser like navigation

Web based applications use the browser as steering wheel of the
application. Browser and link based navigation is a great advantage
over desktop like applications which always require following menu
sequences.

I believe that single page technologies should try as most to take
over advantages of multi page applications. In my initial article, I
called such applications unified applications. On the Devoxx
conference somebody used the term hybrid applications.

Google Web Toolkit is on the way to leverage the browser
navigation while JavaFX is spinning and bouncing.

Best Regards
Sebastian Hennebrueder

Devoxx 2009 Presentation - Selecting Web Technologies

2009-11-17T23:00:00Z

Hello,

I provided the slides and some links of the presentation.

Download of the presentation

Article on web technologies

Evaluation and test of Stripes

Evaluation and test of Tapestry

Evaluation and test of JSF 2

Best Regards

Sebastian Hennebrueder
Independent Software Developer
Trainer for Hibernate and Java Persistence

Window id - browser extension

2009-11-13T00:00:00Z

Browser extension

I discussed the idea of a window id on the following page http://www.laliluna.de/articles/window-id-concept.html
and
http://www.laliluna.de/articles/2009/05/28/browser_feature_request_sample_application.html.

The window id is passed as request header “X-Window-id” and is unique per browser tabulator.

This approach allows to store data in the session per window and provides a better control in web application, if the user opens multiple window.

In my opinion, this should be solved in the browser but meanwhile we can achieve this using a browser extension. I have written one for Firefox and are planning to write one for IE and Safari/Chrome as well.

The extension is published under the [RobinHood licence 0.1](http://www.laliluna.de/open-source-robin-hood-license.html).
There is a usage limit only for companies and organizations. A licence is required, if your company’s turnover or organization budget exceeds a limit of 2 million Euro.

Install Window Id Extension!
(Browser might block install, Check the info area at the top of the browser)

Best Regards/Viele Grüße

Sebastian Hennebrueder

JSF 2 - evaluation and test

2009-11-01T00:00:00Z

JSF 2 – evaluation and test

Introduction

JSF is a standard to implement Java based web framework. There is
a reference implementation of the standard, Mojarra JSF, which
provides the request processing and a set of basic components. JSF is
component oriented and as such it brings the concepts of desktop
application development to web application.

JSF 2 introduces a number of new features. It provides a
standardized mechanism to support Ajax, input validation using
annotations (JSR 303), facelets as default rendering engine and a
couple of more features required by modern web application.
The standard implementation does only provide basic components
which mirror the standard HTML input components but one idea of the
standard is that other companies can provide component libraries with
advanced widgets like trees, grids etc. There are a number of third
party component libraries like ADF Faces, Trinidad, ICEFaces,
PrimeFaces, RichFaces, NetAdvantage, JViews and many others.

We have tested a snapshot of 2.0.0 of the reference implementation
(Mojarra) which is released under the Common Development and
Distribution License (CDDL) + GPLv2 and JSF is open source. This
version is of course not yet stable, but I will friendly overlook the
existing bugs in this evaluation.

The test took place from July to
November 2009.

Website <https://javaserverfaces.dev.java.net/>

The tester are Holger Brade, independent software developer at
Munich, Germany and me, Sebastian Hennebrueder, independent software
developer and trainer for Hibernate and JPA at Frankfurt, Germany.

Tools

I used Visual Paradigm to create the sequence diagrams. It is a quite powerful UML solution with support for Java round trip engineering. It detects JPA and Hibernate entities as well. <http://www.visual-paradigm.com/>

Table of Content

1 Introduction 1
2 Hello world 2
3 Discussion 5
3.1 Architecture 5
3.2 Dependencies and libraries 17
3.3 Flow of development 17
3.4 Popularity and contributor distribution 17
3.5 Sebastian’s opinion on the framework 17
3.6 Holger’s opinion 22
3.7 The community’s opinion – beautiful features and concepts 23
4 Features 23
4.1 Render / page technologies 23
4.2 Developer comfort 23
4.3 Ajax support 24
4.4 Security 25
5 How do I do …? 26
5.1 Navigation 26
5.2 Friendly URLs 29
5.3 Templates 32
5.4 Forms and validation 33
5.5 Common dialog tasks 40
5.6 Message resources and internationalization 43
5.7 Exception handling 45
5.8 Redirect on post and flash scope 47
5.9 Conversation context, wizards and workflows 47
5.10 Double submit handling 52
5.11 Custom components 52
6 Performance and scalability 61

Hello world

The hello world application intends to show how complex it is to
setup a simple application. It renders an index page with a link.
Following the link calls an action of the framework and stores a
localized message. The user is send to a view displaying this
message.
You can download the sample project helloworld at
<http://www.laliluna.de/download/framework-evaluation-samples.zip>

Requirements:

A servlet engine or an JEE application server like Jetty, Tomcat
or Glassfish. The example was successfully tested with Jetty 6.21,
Tomcat 6.0.14 and Glassfish v3-preview.

Required steps

Create a new web application.

Add the following libraries to the build path of the web
application.

jsf-api-2.0.0-SNAPSHOT.jar
jsf-impl-2.0.0-SNAPSHOT .jar
jstl 1.2 (might be removed)

The deployment approach for JSF libraries is slightly picky.
Glassfish provides already JSF 2 libraries. You may need to update
them using the update mechanism of Glassfish. Just search for
‘glassfish JSF2’ to find more information.

Jetty 6 requires that the libraries are copied to
JETTY_HOME/lib/ext/ You may create a subdirectory as well. Sample:
JETTY_HOME/lib/ext/jsf-2.x/

Tomcat 6 is fine, if you deploy the libraries with your web
application. They can be added to the WEB-INF/lib folder of the
deployed WAR archive.
You have to provide the JSTL library even if you don’t use it.

Modify the web.xml

The Servlet class FacesServlet starts the JSF request processing
life cycle and must be defined in the web.xml. The servlet mapping
tag defines the for which URL the FacesServlet should be executed.
The pattern /faces/* is commonly used by the JSF specification but
any other prefix or extension is possible. The example uses as
web-app attribute version=“2.5” this means we are using
servlet-api version 2.5. If you use tomcat 6 we need minimum
servlet-api in version 2.5. Compared with jsf 1.2 nothing changed in
this example.
Below you can see the web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee web-app_2_5.xsd"
version="2.5">
  <context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>client</param-value>
  </context-param>
<display-name>HelloWorld with JSF RI 2 (Beta 2)</display-name>
<servlet>
<display-name>FacesServlet</display-name>
<servlet-name>FacesServlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>FacesServlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
</web-app>

Create a resource file

The resource bundle for messages is stored in the file
message.properties in the java package
de.laliluna.examples.jsf2.

Add a message for the key hello_world.

hello.world=Hello world

We want to make the resource messages available in the pages.
Therefor we need to configure it in the faces-config.xml. The
file is located in webRoot/WEB-INF/faces-config.xml. In
addition to the resource bundle, we need to specify which locales are
supported. If you don’t specify the locales, then a user with a
different locale than yours might see a ‘Resource bundle not found’
exception.

<?xml version='1.0' encoding='UTF-8'?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
    version="2.0">
  <application>
    <locale-config>
      <default-locale>en</default-locale>
      <supported-locale>de</supported-locale>
      <supported-locale>en</supported-locale>
    </locale-config>
    <resource-bundle>
      <base-name>de.laliluna.examples.jsf2.message</base-name>
      <var>m</var>
    </resource-bundle>
  </application>
</faces-config>

Navigation

In JSF 1.2 navigation rules were explicitly defined in the
faces-config.xml. In JSF 2 we have an alternative: the implicit
navigation. An outcome value like ‘response’ is automatically mapped
to the file /response.xhtml.

The hello.xhtml is the first page we see. It displays a link

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:ui="http://java.sun.com/jsf/facelets">
<head>
<title>Simple JSF 2 example (start)</title>
</head>
<body>
<h:form id="form">
<h:commandLink action="#{sampleBean.storeMessage}">Go to hello world</h:commandLink>
</h:form>
</body>
</html>

The input form is posted and the action storeMessage of the
class SampleBean is executed. It stores the message and
returns the outcome ‘response’. JSF will render the page
response.xhtml.


@ManagedBean
public class SampleBean {
  private String message;
  public String storeMessage(){
    FacesContext context = FacesContext.getCurrentInstance();
    ResourceBundle bundle = context.getApplication().getResourceBundle(context, "m");
    message = bundle.getString("hello_world");
    return "response";
  }
  public String getMessage() {
    return message;
  }
}

The response.xhtml looks like

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
  xmlns:h="http://java.sun.com/jsf/html"
  xmlns:f="http://java.sun.com/jsf/core">
<head>
  <title>Simple JSF 2 example (response)</title>
</head>
<body>
  Message: #{sampleBean.message}
</body>
</html>

That’s it.

Discussion

Architecture

Components

JSF is a component oriented framework. A page or better a view (to
use the JSF terminology) doesn’t consist of text but of components.
Below you can see a sample view.

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/"
    xmlns:ui="http://java.sun.com/jsf/facelets"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:l="http://www.laliluna.de/components/sample">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <title>Facelets - Template Example</title>
</head>
<body>
  <div><l:hello /></div>
  <h:form>
    <h:inputText value="#{inputBean.text}"/>
    <h:commandButton actionListener="#{inputBean.logText}" value="Send" />
  </h:form>
</body>
</html>

The view is parsed and a tree of components is created. Below you can
see a simple component tree.

javax.faces.component.UIViewRoot
- com.sun.faces.facelets.compiler.UIInstructions
- com.sun.faces.facelets.compiler.UIInstructions
- de.laliluna.howto.components.MyHelloComponent
- com.sun.faces.facelets.compiler.UIInstructions
- javax.faces.component.html.HtmlForm
-- javax.faces.component.html.HtmlInputText
-- javax.faces.component.html.HtmlCommandButton
- com.sun.faces.facelets.compiler.UIInstructions

Every component extends UIComponent. To be more precise in JSF 2 it
is recommended to extend UIComponentBase which extends UIComponent
and provides a number of utility methods. When the view is rendered,
JSF asks the root component to render itself, which in return will
ask all of its child components to render themselves. The whole tree
is traversed to render the response. You will find more details on
the rendering later in this article.

Behaviours for components

JSF 2 introduces the concept of
behaviours. You may think of the ‘Strategy pattern’, which separates
behaviour from a class and allows to interchange the behaviour
afterwards. In JSF 1.x existed a kind of behaviour as well. You can
add a converter or a validator to a input field.
Sample for input field which expects a
date and convert the input value to an instance of the class Date.

 <h:inputText value="#{inputBean.moved}">
  <f:convertDateTime dateStyle="short" type="date"/>
</h:inputText>

The concept is now improved with a more neutral named ClientBehavior
interface. The idea is to add client side JavaScript and JavaScript
to a component. This allows to transform a input field to an
autocomplete field or a calendar input.

Lifecycle

The processing of a request is called lifecycle in JSF. There are
different phases which are executed one after the other. If you
prefer design pattern terminology it is a ‘Chain of responsibilities.
A simple GET request has a shorter lifecycle. It the GET fetches a
CSS, JavaScript, image or other content which is provided as a
resource (see resource handling later in this article), then the data
is immediately delivered.
If the request is for a facelet which doesn’t have any parameters,
then two phases are needed as shown in the following diagram.

Before and after every phase events are created to allow event
listener to execute. We will have a closer look at events later.
The lifecycle of a GET request with parameter or of a POST request
has a number of more phases, which either deal with input parsing,
converting and validating or with calling of action and action
listener. You can find the diagram below.
There are three phases which deal with input handling:

Apply Request Values
Process Validations
Update Model Values

A component which does not expect any input will do nothing during
this phases. But a component which expects input will extract the
value from the request during the Apply Request Values Phase
and store it as String value. If the validations for the input
value fails in the validation phase, then this extracted value will
be redisplayed.
In the Process Validations Phase the submitted value is
converted from String to the expected type. Than all validators are
executed. If a validation fails, the processing is stopped after the
validation phase and the processing continues with the Render
Response Phase. If the validation was successful the processing
continues with the Update Model Values Phase.
In the Update Model Values Phase the model is updated. For
example the input text field

 <h:inputText value="#{inputBean.text}"/>

will update the field text of the managed bean inputBean.
JSF offers a base class to be used for components which expects
user input: UIInput.

The phase Invoke Application will
broadcast the InvokeApplication event. This means that the
action listener and the action methods are called. Action listener
are called first. The following command link will call the action
listener foo and the action method bar. The difference
between the two is that the action method can influence the
navigation flow. It returns a String which represents an navigation
outcome.

<h:form>
  <h:commandButton actionListener="#{aBean.foo}" action="#{aBean.bar}" value="Send"/>
</h:form>

The following picture shows the complete lifecycle of JSF.

Every phase can set the boolean flags
renderResponse or responseComplete. RenderResponse will
short circuit to the Render Response Phase. ResponseComplete
stops the processing completely. The renderResponse flag is
for example used during the Validation Phase in case the
validation failed.

Facelets support now partial view rendering for an Ajax request. If
the Ajax request asks only to re-render a specific component, then an
extract of the component tree can go through the lifecycle and render
itself.

Site note: There are different options
to short circuit the processing with immediate attributes for buttons
and links. I don’t want to detail this in this short introduction.

Restoring and saving state

Restoring and saving state is actually part of the lifecycle but
it is slightly complex and I would like to explain it in more detail.
A component can save its state. State includes for example the
value of attributes. The next request can restore the state. For
example, a table component can store the rows, columns and the
selected rows. The next POST request will restore the state and now
you can easily detect if the selected row has changed. The state is a
snapshot of the component tree taken after the response was rendered.

The state can be stored on the client as hidden field, which is
automatically added to all forms or alternatively on the server in
the user session. The first approach has the advantage that no memory
is consumed on the server but the amount of data send around with a
form submit will increase. The length of the hidden field value grows
with the amount of saved state.
Using JSP as rendering technology follows the approach of JSF 1.x
which stores the full component tree. Facelets follows a different
approach. It creates the component tree from the template and then
applies the saved state to the component tree. This approach is
called partial state saving. The size of this partial state is a lot
smaller as compared to full state saving. The tradeoff is that the
restoring of the state takes longer.
The chapter which explains how to write a component, explains how
to implement partial state saving.

Events

From a conceptual point of view, JSF looks like a desktop
application. There are components and events. Components can create
events and can react (or listen) to events. The event concept of JSF
is not simple because there are a lot of different events and there
are a lot of places where events are actually created.
I will try to make this chapter the simplest guide to JSF events.
There are three types of events:

System events
Phase events
Application events.
System and phase events are both created by JSF independent of
your application.

Phase events

Phase events are coarse grained. They are broadcasted before and
after every phase. A use case for a listener of a phase event is for
example a security framework. You can use phase listener to check
access before a phase is entered. A phase listener can stop the
lifecycle processing by setting the flags renderResponse or
responseComplete . Both have been explained in the lifecycle
paragraph.
You can register global phase event listener and per view phase
event listener. Global phase listener are executed for all requests
whereas per view listener only for a request of the specific view.

Here is an example for a global phase event listener. It is
configured in the faces-config.xml.

 <faces-config ...>
  ...
  <lifecycle>
    <phase-listener>
      de.laliluna.howto.services.GlobalPhaseListener
    </phase-listener>
  </lifecycle>

You can add global phase listener programmatically as well. The Lifecycle provides methods to add and remove phase listeners.

LifecycleFactory lifecycleFactory = (LifecycleFactory)
FactoryFinder.getFactory(FactoryFinder.LIFECYCLE_FACTORY);
Lifecycle lifecycle = 
    lifecycleFactory.getLifecycle(LifecycleFactory.DEFAULT_LIFECYCLE);
lifecycle.addPhaseListener(new GlobalPhaseListener());

Phase listener can be added per view as well. Just add the following
tag to the page.

 <f:phaseListener type="de.laliluna.howto.services.PerViewPhaseListener" />

Alternatively you can add such a listener programmatically. You need
to extract the root component from the FacesContext and call addPhaseListener

 viewRoot.addPhaseListener(listener);

There are two limitations for view specific phase listener. First, as
the view needs to be created for a per view phase listener, you
cannot get any events for the RestoreViewPhase . Second, a GET
request to a page, which expects parameters, does only trigger the
RenderResponse phase events.
A phase listener is just a class implementing the PhaseListener
interface. The method getPhaseId returns a value which
specifies in which phase the listener is called.

package de.laliluna.howto.services;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
public class PerViewPhaseListener  implements PhaseListener {
  private Logger logger = Logger.getLogger(PerViewPhaseListener.class.getName());
  public void afterPhase(PhaseEvent event) {
    logger.info("per view phase listener, after: "+event.getPhaseId());
  }
  public void beforePhase(PhaseEvent event) {
    logger.info("per view phase listener, before: "+event.getPhaseId());
  }
  public PhaseId getPhaseId() {
    return PhaseId.ANY_PHASE;
  }
}

System events

System events is an innovation of JSF 2. Those events are created
at various moments of application or request lifetime.
There are system events which are global and others which are
related to a component. Event listener can be configured in the
faces-config.xml, programmatically or using annotations.
In the following sample you can see an event listener, which is
called after the application has started and JSF finished the
configuration, and an event which is executed before the application
is shutdown.

 <faces-config ...>
  <application>
    <system-event-listener>
      <system-event-listener-class>
          de.laliluna.howto.services.StartUpConfiguration
      </system-event-listener-class>
      <system-event-class>
          javax.faces.event.PostConstructApplicationEvent
      </system-event-class>
    </system-event-listener>
    <system-event-listener>
      <system-event-listener-class>
          de.laliluna.howto.services.StartUpConfiguration
      </system-event-listener-class>
      <system-event-class>
          javax.faces.event.PreDestroyApplicationEvent
      </system-event-class>
    </system-event-listener>
  </application>

An example to register a system event listener programmatically:

Application application = FacesContext.getCurrentInstance().getApplication();
application.subscribeToEvent(PreRenderViewEvent.class, new MySystemEventListener());

For components and renderer the system event listener can be
registered using annotations as well:

@ListenerFor(systemEventClass = PreRenderViewEvent.class)

A final option is to configure the event listener inside of the
template. The <f:viewParam> is a component which writes
a request parameter into a managed bean variable. The *preRenderView

event will trigger execution of the load method, which will load
an article for the given id.

<f:metadata>
 <f:viewParam id="id" name="id" value="#{articleBean.id}"/>
 <f:event type="preRenderView" listener="#{articleBean.load}"/>
</f:metadata>

There are about 16 different system
events. You can easily find them by looking for sub classes of
javax.faces.event.SystemEvent .

System event listener are fine grained
compared to Phase listener. Some are related to new features of JSF 2
(sample: PreDestroyCustomScopeEvent ), some let you control
behavior of your components.

Application events

Application events are created by your components. JSF 1.x had two
types of FacesEvents:

ValueChangeEvent
ActionEvent

The event ActionEvent is used by the component class
UICommand , which is the base class for the command link,
command button etc. The event is queued during the ApplyRequestValue
phase. Later in the InvokeApplication phase, the events are
broadcasted and action methods and listener are executed.
The event ValueChangeEvent is queued, if the validation of
user input was successful and the value has changed. It is
broadcasted during all following phases.
JSF 2 add events related to behaviors and Ajax ( BehaviorEvent,
AjaxBehaviorEvent). Both events are used in the new component
behavior concept. The concept allows to add behavior to existing
components. An input field may offer autocomplete values or react to
the browsers onBlur event.

Technical details

The following diagram shows all places where events listener are
called. The diagram is slightly simplified. The FacesServlet is the
entry point of the JSF application. It calls the lifecycle, which in
return executes the different phases. Every phase calls global phase
event listener before and after the actual work is done. Sample: 3
and 4 in the RestoreView phase.
PhaseEvent listener can be defined per view as well. These
listener are called by the root component, UIViewRoot. This happens
in the diagram for example at 9 and 14.
FaceEvents (alias Application events) are broadcasted by the
UIViewRoot component. This happens in every phase. Sample: 12, 21,
28.

System events are broadcasted immediately at various points in
JSF. Just search the source code for publishEvent.

An interesting point of event broadcasting is number 35. The event
broadcasting will as well call all action listener and action
methods.

Managed Beans

Managed Bean are the key player in your web application. They can
receive input values, provide data for output and provide action
listener and action methods. Action methods can influence the
navigation where as action listener cannot. In most applications
managed bean are the bridge between the web application and the
business logic.

Managed Beans are managed by JSF. They are instantiated and stored
in a context. There are different contexts. JSF calls them scopes:
Session, Request, View, etc.

The following is an example for a managed bean with session scope.
It increments a counter showing how often it was called during the
current user session.

package de.laliluna.howto.beans;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import java.util.concurrent.atomic.AtomicInteger;
@ManagedBean
@SessionScoped
public class SessionScopeSample {
  private AtomicInteger count = new AtomicInteger();
  public int getCount() {
    return count.getAndAdd(1);
  }
}

The template contains the following code

In the user session, you have called ‘getCounter’ of the SessionScopeSample bean #{sessionScopeSample.counter} times.

The first time, you visit the page an instance of SessionScopeSample is created and stored in the session scope. In
subsequent calls JSF gets the instance from the session scope and
reuse it.
Scopes are Application, Session, View, Request and None.

None will create a new managed bean every time it
is used. The View scope lifecycle is started when entering a view
with a GET request. If you reload the page a new view scope is
started. If you send a POST request the old view is restored and the
view scope is reused. The view scope is destroyed if an action method
sends you to another view.
At the time of writing it was unclear
what happens if you leave the page with a GET request without a call
to an action method. The other scopes correspond to their servlet
spec equivalents.

Very interesting are custom scopes.
This is a new feature of JSF 2 and let you build for example a wizard
scope to be used, if you want to build your own dialog wizard or a
scope to integrate a business process engine.

Managed beans can be configured using
annotations and XML in the faces-config.xml .

Another feature of managed beans is
configuration of a managed bean. You can set properties to values or
inject other managed beans. You can only inject beans with a longer
lifetime into another managed bean. Managed beans are in fact a
simple form of an Inversion of Control container.


 @ManagedBean @RequestScoped
 public class RequestScopeSample {
  
  @ManagedProperty("foo is foo")
  private String foo;
  
  @ManagedProperty("#{viewScopeSample}")
  private ViewScopeSample viewScopeSample;
   // setters are omitted here for brevity BUT are REQUIRED for injection
 }

If you use JSF inside of a JEE container you can inject resources,
session and message driven beans and webservices into your managed
beans.
A final feature of managed beans are
listeners to lifecycle events. You can react to the creation and the
destruction of a managed bean.

 public class RequestScopeSample {
  @PostConstruct
  public void postCreate(){
    logger.info("RequestScopeSample bean is created");
  }
  @PreDestroy
  public void preDestroy(){
    logger.info("RequestScopeSample bean is destroyed");
  }
}

Extension points

JSF offers a variety of extension points. The most important
extension points are the classes
javax.faces.application.Application and javax.faces.FactoryFinder,
phase listener and custom component.

The Application class is a central class in JSF. It
provides access to most information of an JSF application, for
example: resource bundles, navigation handler, action listener,
supported locales etc. There is only a single instance per
application. It can be configured by entries inside of the
<application/> tag in the faces-config.xml. The chapter
User-friendly URLs contains an example
The Application class and mainly everything else in JSF is
created by factories.

Factories can be located by a factory finder.
The FactoryFinder class is a final class which provides access
to about 10 different factories. Every factory can be replaced with a
custom factory. The configuration takes place inside of the
<factory..> tag in the faces-config.xml .
Factories create for example the FacesContext, a class holding all
information relevant to a request. In addition there is an exception
handler factory, which allows to customize the exception handling
(see chapter exception handling), there is a lifecycle factory which
allows to customize the creation of the JSF lifecycle.
Phase listener is another option to integrate customized
functionality in JSF. It can be used to integrate code that is
executed before and/or after a specific phase.

The final option are custom components. Components are elements
used in templates. There are visual components displaying for example
input forms and fields and non visual components, which are used to
configure validation methods, view parameters or view specific event
listener.

How to integrate a business layer?

We have discussed already that Managed Beans are the bridge
between a JSF application and the business logic.
The simplest way to access your business services is to implement
a ServiceFactory which creates your business services.

@ManagedBean @RequestScoped
public class ArticleBean {
// ...
  public void load(){
    if(id == null)
      return;
    ServiceFactory factory = ServiceFactoryImp.getInstance();
    ArticleService articleService = factory.getService(ArticleService.class);
    article = articleService.findById(id);
  }
}

This approach is not very comfortable. It would be a lot nicer, if we
can inject a service using an annotation.

  @ManagedProperty(value = "#{articleService}")
// or like this: @Inject
  private ArticleService articleService;
  
  public void load(){
    if(id == null)
      return;  
    article = articleService.findById(id);
  }

The good message: If you use EJB 3 and implement your business logic
using session beans, then the problem is already solved. You can
inject sessions beans using the @EJB annotation.
How do we solve this for Inversion of Control / Dependency
Injection Frameworks like Google Guice, Hivemind, Pico Container or
the Spring framework? The approach is pretty much the same for all
frameworks. We just need to provide our own
expression-language-resolver. The resolver finds and creates objects
referenced in EL-expressions like #{articleService}. Google
Guice and the Spring Framework already provide a resolver. In order
to show all required steps, I will not use one of those finished
solutions but show the integration of the Framework Pico Container.

A quick site note on EL resolution:
An EL-resolver provides a method getValue(ELContext elContext,
Object base, Object property) to resolve an expression. An
expression like #{foo.bar.baz} is split into its parts and
resolved step by step. GetValue is first called for the
property foo with a base value of null. If foo resolves to an object, then the method is called with this object
as base value and bar as property value. In the last step, the
resolved value of bar is used as base value and baz as
property value.

Now, let’s create our own resolver. First, we need to tell JSF
that it should add our resolver in addition to the default resolvers.
Add the resolver to the faces-config.xml .

 <faces-config ...>
  <application>
  <el-resolver>de.laliluna.howto.application.PicoBeanELResolver</el-resolver>
  ...

Then you need to implement your own resolver. It must extend the
class javax.el.ELResolver. There are 6 methods to override.
The following four are important.

getValue – is called when a property is resolved
setValue – is called when a value is assigned to an expression, a Inversion-Of-Control container will not allow this in
most cases
isReadOnly – returns true, if a resolved value is read
only. As resolved business services are read only, we return true,
if we can resolve a bean
getType – is called before setValue is called. It
returns the type which can be assigned to an expression. We need to
implement it but it is in fact never used, as we support only read
only values.

Here is an extract of the source code

package de.laliluna.howto.application;
import de.laliluna.howto.services.PicoObjectProvider;
import org.apache.log4j.Logger;
import javax.el.ELContext;
import javax.el.ELResolver;
import javax.el.PropertyNotFoundException;
import javax.el.PropertyNotWritableException;
import java.beans.FeatureDescriptor;
import java.util.Iterator;

public class PicoBeanELResolver extends ELResolver {
  private static Logger logger = Logger.getLogger(PicoBeanELResolver.class);
  
  public PicoBeanELResolver() {
    // init the Picocontainer
//    It is better to add a startup listener instead of doing this here !!!!
    PicoObjectProvider.getInstance().startUp();
  }
  
  public Object getValue(ELContext elContext, Object base, Object property) {
    // the resolver resolves only names without prefix.
    if (base != null) {
      return null;
    }
    if (property == null) {
      throw new PropertyNotFoundException("Could not resolve property, as property name is null");
    }
    PicoObjectProvider provider = PicoObjectProvider.getInstance();
    Object result = provider.provide(property.toString());
    if (result != null) {
      elContext.setPropertyResolved(true);
    }
    return result;
  }
  
  public Class<?> getType(ELContext elContext, Object base, Object property) {
    Object value = getValue(elContext, base, property);
    return value != null ? value.getClass() : null;
  }
  
  public void setValue(ELContext elContext, Object base, Object property, Object val) {
    Object value = getValue(elContext, base, property);
    if (value != null) { // should never happen, as readonly returns true
      throw new PropertyNotWritableException("Objects resolved by the Pico Container are not writable");
    }
  }
  public boolean isReadOnly(ELContext elContext, Object base, Object property) {
    return getValue(elContext, base, property) != null;
  }
// ...

That’s it.
An alternative approach to managed bean is to create the managed
bean already by the Inversion of Control Framework. This approach is
used by the Spring Framework or the Web Beans JSR. The advantage is
that the managed bean can be a part of the lifecycle of the IOC
container and integration of advanced scopes like wizards, workflows
etc are simpler. A disadvantage of such an approach is that the web
and the business layers start to flow into each other and make it
harder to test the business layer independently.

Dependencies and libraries

JSF 2 requires only 3 libraries

JSF API
JSF implementation
JSTL 1.2

You need JSTL even if you use only facelets.
The ‘Hello World’ example stated some application server specific
deployment requirements.
If you want to use Bean Validation (see below), then you
will need the two additional JARS.
If you use a component library like MyFaces, ADF, Richfaces,
Icefaces etc then you will need those additional libraries.

Flow of development

Building a new dialog normally requires a new facelet page to be
created, a new managed bean and in some cases a new navigation rule
in the faces-config.xml. Most
changes requires a reload of the application. Exception to the rule
are facelets page changes, and changes inside of a Java class method.
You can improve the development speed by using Groovy instead of Java
to implement components and managed beans. Have a look at the groovy
chapter of this article.

Popularity and contributor distribution

Google pages on JSF 2: about 7,000,000
Books: Currently none but there are
quite some books in preparation

Number of mails on mailing list per
month: 750 (as JSF is only a standard and Mojarra is only one
implementation, this is not the number of all discussions on JSF.
Every component collection has its own website.)
Number of core developer, regular
patcher/contributors

The numbers are hard to estimate and
probably less informative as the JSF landscape will have a number of
JSF implementation, including the reference implementation of JSF
(Mojarra) and a number of component collections. Apart from MyFaces
most component collections are backed by a single company.

Sebastian’s opinion on the framework
There is light and there is shadow. JSF 2 is a major step forward
in quite a number of areas. Navigation with GET requests is now
possible and implicit navigation as well. Implicit means that you
don’t have to create navigation rules in an XML file as before but
you can just return a string from an action method like ‘result’ and
you will navigate to the page result.xhtml .

Facelets are now the default mechanism to create pages. A facelet
page is written in xhtml format. Facelets provide a quite flexible
template model and renders faster as compared to JSP based pages. An
additional advantage is the ease to integrate custom components. You
just include the namespace of your component taglibrary and you get
autocompletion for your own components, if your IDE supports it.
The approach to handle resources like CSS, JavaScript or images is
a great feature as well. The resources are packaged into a directory
structure, which may include a locale or a version prefix like
de/css/test.css/1.1.css. This approach allows to deliver
different CSS, JavaScript or images for specific locales and in
addition you can managed different versions of a file as well. Per
default the newest version is delivered but you may define for a page
that an older version is used. I am not aware of a framework
providing the same flexibility for resource handling.
Finally, the code is very easy to understand and nice to read. The
Mojarra implementation is written by people, who knows how to code.

Let’s have a look a the dark sides.

Overall impression

JSF looks like an old castle, where every generation added pieces,
towers and buildings. I don’t blame the developers for this, as the
code shows, that they know how to do a proper job. I believe that the
reason for the current status of JSF is that the features are defined
by a specification. The specification is industry driven with a focus
on being backward compatible instead of being technology driven.
Everything works somehow but always rather complex than simple. Every
release makes it worse as nothing is dropped. I am sorry, but I can
only see a bad ending for such a strategy.
Pages are extremely verbose. Using it make you feel being
unproductive most of the time. JSF 2 brings some innovation but in a
lot of areas it doesn’t even catch up with the current status of
other frameworks. It is likely to be outdated before it is actually
stable.
I wouldn’t use it for new projects and especially not for large
enterprise projects. In my opinion, there are two use cases to choose
JSF. The first use case is a project where the development team has
only experience with JSF, you are willing to accept higher
development costs and prefer that a technology changes slowly. The
second use case is an existing application using JSF 1.x which allows
you to keep the old stuff. In that case a migration to JSF 2 is an
acceptable choice.

Being a standard

A lot of people, see the fact that JSF is standardized, an
advantage. I do not agree here for a number of reason. First of all,
even using JSF you cannot write an application which uses only
standardized technologies. The JSF spec describes mostly the request
processing, navigation and basic components but not all advanced
features. Today, basic components which mirrors HTML elements are
just not enough. As a consequence, all component providers build
their own approaches to fulfil modern requirements. Most users chose
a modern component library to implement JSF application with modern
Ajax behaviour. All advanced features were not standardized and are
not compatible across component libraries. You end up with a thin
standardized layer and the rest is a set of non standardized
components. You choose one component provider and stay with it. If
you want to switch the component collection, then you will most
likely rebuild or migrate all dialogs.
The only advantage of standardizing is to create a rich community
of competing component projects. Competition encourages innovation.
Having a closer look at the different component collections, shows
that some collections are deprecated and most popular collections are
backed by a single vendor and not by a community. The only popular
community based component collection is MyFaces. But this project
though not being already dead, suffers from extremely slow progress
and little interest. A lot of elements have not changed for ages, it
lost the status of being the best JSF implementation. In my opinion,
the standardization did not encourage a rich community but the
opposite is true. A community grow only around attractive frameworks
which provides a high value for the users.
The second problem of standardizing is that a standard is a
compromise and it progresses very slowly. A compromise does not
include very innovative or individual features and needs to ensure
that it doesn’t change vertically. Changing vertically means that it
adds more responsibility as it had before. In JSF 1.x Ajax behaviour
were not defined. Every component provider solved Ajax requirements
differently and now JSF 2 introduces its own mechanism.
There is a fair chance that components collections do collide with
the new approach and they are left with basically two choices. Either
the libraries drop backward compatibility and adapt the new JSF 2
features or they stay old fashioned and just ignore it. In the latter
case, it is hard to predict how components libraries play together
with the standard JSF 2 Ajax, in case somebody mixes both approaches.

Burden of backward compatibility

The third problem of the JSF standard is the burden of backward
compatibility. Technologies live in a triangular space and choose
between a mixture of three extremes:

Being genius and having all future requirements already
correctly forecasted
Changing continuously and breaking backward compatibility
Changing slowly and preserving backward compatibility

The first extreme is rare, the second destroys your community as
users are annoyed every time they upgrade and need to adapt to a
changing API, the third one destroys the technology as it will become
outdated, bloated and inefficient in short time.
JSF were introduced in 2004 a time Ajax were unknown. Since then
web applications has changed a lot and today we have to build complex
Ajax dialogs. A development which lead to a number of single page
technologies like GWT, Flex, Java FX etc. Still JSF preservers
backward compatibility just adding features around the existing
stuff. There are now two types of resource bundles, three types of
events and two types of components. This makes it quite hard to use
JSF correctly and becomes a burden to all new users. Community driven
frameworks are normally technology driven as well and adapt
continuously to new requirements. JSF is industry driven and is not
able to drop old stuff as there will always be a party to complain.
For JSF being a standard becomes more and more its own pitfall.

By the way, standards are not a danger by default. The EJB spec
shows that a standard can be successful and innovate at the same
time. I think the main difference between EJB and JSF is that EJB has
a defined focus which is not changing and the elements of EJB are
loosely coupled. There is a programming model and a description of
container responsibilities. The programming model could
change/innovate significantly and old and new stuff still works.
Loosely couple systems are a very important approach to be able to
innovate technologies. This is the reason, why I value technologies
like Grails, JBoss Seam or an application using the full Spring stack
extremely critical. Today they are all very innovative and powerful
but if any element of these integrated solutions doesn’t work for a
specific use case or might become deprecated, then the whole stack
looses value or becomes use less.

Components

JSF offers two types of components: composite components and the
classic ones. Composite components are introduced with JSF 2. I would
call it a snippet instead of component, which allows to render a
number of components using a single custom tag. I think that it is a
mistake to introduce a new component approach and to leave the old
heavy components which have quite a number of contracts to follow.
Composite components are of course a great help but they lack the
Java code you can use in real components and it is only a help
because writing components in JSF is very complex. Writing custom
components is frequently used to ensure a consistent look and feel in
large enterprise application. Modern frameworks like Google Web
Toolkit (GWT), Tapestry or Wicket try to make this as simple as
possible. As a consequence, it is a common and frequently task for
developers using those technologies. In JSF writing of components is
a job for experts only. In fact most people use only finished
component collections and would never write a component themselves.
In my opinion, this is one of the strongest weaknesses of JSF 1.x and
it is not fixed with JSF 2 and as the JSF interest groups are mostly
industry companies preferring backward compatibility over efficiency
and innovation we won’t even see it fixed in any JSF version.

Scopes

JSF introduces now a flash scope, a view scope and support for
custom scopes. A flash scope is important to implement proper
post-redirect-get dialogs. It is not an innovation but catches up
with a feature available in all other frameworks. I think that the
use of the flash scope could be more elegant as it is quite verbose
and different as compared to other scopes like session or request
scope. I would expect a unique approach to deal with all scopes. The
view scope is slightly useless. The reason is that it works only, if
you use the old style POST navigation approach. I think that it was
overlooked that the new links or buttons, which cause a direct
navigation using a GET request will create a new view every time.
There is no defined point in time destroying the view scope. You
might run into memory issues, if you use it incorrectly.

Making such a scope work correctly is not at all easy. The reason
is that we use state in a multi-page web application and we don’t
have full control over the user. He can use browser back and forward
and reposting, bookmark URLs he shouldn’t. Other approaches
organizing the state around a conversation id looks better on the
first look but while using them, you find out quite fast, that it is
actually very difficult to create clean borders in your web
application, which cause a conversation state to end. This is why, I
promote the idea of a window id to be sent by a browser. This would
allow a much better control about what the user is doing inside of a
window.
http://www.laliluna.de/blog/categories/ideas/

Validation

The validation can be ajaxified with the new <f:ajax>
tag. Leaving an input field will validate the input for that field.
An Ajax request is sent to the server, which causes a partial
processing of the input element. This is much better than waiting for
a form submit but could cause DOS attacks against the server. Just
press the TAB-button, let the cursor jump from input field to input
field and see how many validations per second the server can process.
In addition, the validation is always delayed. A better approach is
to do the validation directly on the client without contacting the
server. The server validation is only a fallback for security reason.
The integration of the Hibernate Validation framework (Bean
Validation spec) looked liked a great improvement on the first view.
You add annotations like @Size or @Length to a field of
the managed bean or directly in an entity bean. This allows to use
the same set of validation rules for Hibernate and for JSF. This is
pretty nice and the integration works like a charm. The problem is
actually not a problem of JSF but of Bean Validation. Somehow in the
last moment, they changed the group validation to use class name
instead of strings. Group validations are an important feature to
validate only some validations instead of all. You need it, if you
use a managed bean for multiple forms like a wizard or multi page
dialog or if you want to have different validations depending on the
use case. Now you have to use the class name everywhere. Every input
field as a group marker like the following:

 <h:inputText value="#{inputBean.address.email}">
  <f:validateBean validationGroups="de.laliluna.howto.beans.Step1"/>
</h:inputText>

Happy copy and pasting. This is another example, that following
standards can be a disadvantage. The bean validation had another
issue, which is described in the related chapter of this article.

Actually, I am waiting for a initiative of a couple of other web
frameworks to create a common validation alternative.

Dependency Injection

Most major frameworks have a Dependency Injection Container now as
core element. Such a container allows to replace, change or extent
all elements of a framework. This is a very powerful approach to open
a framework for customized extensions. JSF provides extension points
as well and allows to override default functionality but there is no
unique place. JSF elements are created by different factories or by
changing application properties where as all business services are
created by the managed bean manager. The Java Dependency Injection
specification (alias Web Beans) has the intention to improve this
situation at least to provide a unique container for managed beans,
session beans and some core elements needed by the application. From
my understanding Web Beans would not replace but only integrate the
set of existing factories. I will update this section once all the
things are available.
To summarize, the lack of a DI container as core of the framework
is a disadvantage of JSF. I assume that this is again a tribute to be
backward compatible.

Future of web frameworks

I will add this section after the Devoxx conference end of November. It is an
outlooked how component oriented frameworks could change.

Notes for JSF developers

I collected some notes, which are mostly interesting for JSF
contributors. None of the notes are critical.

The class UIViewParameter has a private rawValue field.
This makes it harder to create a sub class. In addition to the decode
method, further methods have to be implemented or copy and pasted.
The MessageFactory could be public instead of package
private to allow using it in other areas as well. Access to resource
bundles is a very common use case.
The class NavigationHandlerImpl could split out view
resolution in order to allow easier overriding. I wanted to find out,
if the view is a redirect in order to store things in the session in
that case.
It is quite hard to provide a custom FacesContext . A number
of areas access FacesContext.getCurrentInstance which by
default delivers the unwrapped default context instead of the custom
context.

Holger’s opinion

AJAX became more and more important for
web applications over the last years. With the support of AJAX in JSF
2.0 it becomes a standard, which allows other components and
libraries to build on that. This improves the compatibility.

In JSF 1.x there is Facelets as
declaration language beside JSP. With JSF 2.0 Facelets becomes the
default page language. It provides templating, alleviate the creation
of components, allows debugging and has a better performance.

Management for resources, scripts and
stylesheets was standardized in JSF 2.0. Now resources can be
overridden and internationalized.

The validation was strong improved. Now
we only have to annotate attributes with the required validation
rules. Redundant validation rules within the JSP page are not
necessary anymore.

In JSF 1.x all navigation rules needed
to be defined in the faces-config.xml. With JSF 2.0 it is possible to
drop the navigation rules and to determine the target page by the
return value of action methods. Navigation in medium application are
simplified considerably.

JSF 1.2 is the standard framework
technology in JEE5 and JSF 2.0 will be the standard in JEE6.
Therefore, there will be many users of JSF.

The community’s opinion – beautiful features and concepts

I asked the following question on the mailing list:

What
is your favourite feature or concept of JSF,
what is unique as compared to other things, what is an eye catcher?

Though I posted the
questions in three forums, I only got two feedbacks. This is an
indicator that even though the number of users are very high, there
is actually no real community being engaged in JSF. The technology is
company driven.

Here are extracts or
rephrased parts of the feedbacks:

Andy Bosch
(translated from German)
My favourite feature is the resource handling. It was quite
difficult in former JSF version especially when using Portlets.

Lincoln Baxter

1. Composite Components — The ability to create fully reusable
components with zero java code required whatsoever. This is called
“EzComp”, which has sped up my development by about 400%.

2. Built in Facelets support for Templating — never re-write
HTML, you can re-use every piece of every page if you want to.

3. Built in AJAX — specify components to submit, and components to
re-render when the request has been processed. Very easy to use, plug
& play, no javascript required (but may be used if desired.)

4. Entire pages of the site, not just components, can be packaged in
their own jar files and included in the main application. No more
massive WebContent directories.

5. Improved community
participation — We are actively seeking feedback from the community,
and trying to get as much feedback and discussion as possible in
order to make JSF2 the best possible solution it can be.

Ed Burns

Ed Burns is a core developer of the JSF reference implementation (Mojarra). He added a detailed comment in his block at <http://weblogs.java.net/blog/edburns/archive/2010/01/21/response-sebastian-hennebrueders-jsf2-evaluation-and-test-entry>

Features

Render / page technologies

The reference implementation allows to create pages using Facelets
or JSP. Facelets are pages in XHTML format, whereas JSPs are JSPs.
The recommended approach is Facelets as it is faster and supports
templates out of the box.

Developer comfort

The developer comfort is still pretty low using Mojarra JSF.
Reloading of components and managed bean still depends on the
reloading mechanism of Java in debug mode. JSF 2 has adapted an idea
from Ruby on Rails. There is a setting which defines if the
application runs in development, production or test mode. The
intention is to allow component provides to deliver a more
development friendly behaviour in case of development mode. You need
to check for the component collection of your choice how it
interprets this value.

The following is a snippet from the web.xml.

 <context-param>
        <param-name>javax.faces.PROJECT_STAGE</param-name>
        <param-value>Development</param-value>
 </context-param>

Facelet and JSP pages can of course be reloaded.

There is an issue with logging in JSF.
JSF relies on Java logging which makes it by default quite hard to
change log levels. The Howto-project provided as source shows
how to bridge the logging to log4j. This allows to use the same log4j
configuration for your application and for JSF internals. Search for
the class LogRedirect . The redirect of the logging is
integrated using a system event listener for the Startup and Shutdown
events.
Mojarra supports Groovy to implement
managed beans and components. As groovy is a dynamic language, you
can make use of reloading of changes, which improves a lot the
development speed.

Ajax support

JSF 2 provides now a number of features to support Ajax. The first
feature is so called partial rendering. Instead of rendering a full
page only a partial response is rendered which is applied to the
document.

There is a new tag <f:ajax> to add Ajax behaviour to
an existing component. The following code shows a command button
which is ajax enabled. If you click the button, then JSF will send an
Ajax request to execute the actionListener *ajaxBean.increase.

Then it will re-render the component with the id counter .

<h:form id="formId">
  The counter value is <h:outputText value="#{ajaxBean.counter}" id="counter"/>
  <h:commandButton actionListener="#{ajaxBean.increase}" value="Ajax call">
    <f:ajax render="counter"  />
  </h:commandButton>
</h:form>

Tip: If the component to re-render is not on the same nested level as
the component sending the Ajax request, then you need to specify the
full qualified name of the component. It starts with a colon <f:ajax
render=“:counter” />

If a component is nested inside of another component, then you need
to take into consideration that JSF is prefixing the outer id to the
component id.

The following counter can be re-rendered using

 <f:ajax render=":foo:counter"/> <h:form id="foo"> <h:outputText value="#{ajaxBean.counter}" id="counter"/> </h:form>

If you disable JavaScript in your browser then the application
will fall back to the default behaviour. The button is no longer Ajax
enabled and submits the form.
The render value takes a space separated list of ids or
alternatively keywords. Keywords can have values like @form, @all,
@this, @none. @form re-renders the form which included the submit
button.

Another interesting attribute of f:ajax is execute. It sends an Ajax request and
processes the lifecycle only for the specified components. The
following code will process all the validations and re-render the
<h:messages> tag afterwards to show validation errors.

<h:inputText id="age" value="#{ajaxValidation.age}" required="true">
  <f:validateDoubleRange minimum="5" maximum="99"/>
  <f:ajax execute="age" event="blur" render="age-error"/>
</h:inputText>
<h:messages id="age-error" for="age"/>

This is quite verbose. To shorten the code you can make use of
composite components, which allows to render a number of tags by
specifying a short composite tag. Have a look in the custom component
chapter. Here is just the tag sample.

 <my:text label="Word (is required)" value="#{ajaxValidation.age}" required="true" />

The JavaScript API provided by JSF 2
allows further control over the Ajax request send to the server.

CSS and JavaScript resource handling

A final feature related to Ajax is the
option to deliver resources. Resources can be JavaScript but as well
images and stylesheets. The following tag adds the test.js to
the head section of the page.

It renders the following XHTML

You need to place resources in the folder resources of the web
root or alternatively on the classpath in the directory
META-INF/resources. It is probably better to group resources
into libraries. Libraries are sub directories of the resources
directory. Here is a sample directory structure:

webroot/resources/css/default.css
webroot/resources/images/foo.gif
webroot/resources/images/bar.gif
webroot/resources/js/myscript.js

My script can now be referenced using <h:outputScript
library=“js” name=“test.js” target=“head”/>. In addition to the library a resource can be injected for a
specific version or locale. This is a very flexible approach to
handle different versions and locale dependent stylesheets or
JavaScript files.
Let’s assume the following directories
and files.

webroot/resources/de/js/default.js/1.0.js
webroot/resources/de/js/default.js/1.1.js
webroot/resources/en/js/default.js/1.0.js

A user with a german locale (de), using the following tag will get
the newest version of the German script
webroot/resources/de/js/default.js/1.1.js

 <h:outputScript library="js" name="default.js" />

A page could use an older version as well. It just needs to specify
the resourceVersion .

 <h:outputScript library="js" resourceVersion="1.0" name="default.js" />

Security

There is no build in security but you will find examples how to
integrate JSF with Spring Security. If you use JSF with JBoss Seam,
you can use its security functionality. Both approaches allow to
protect pages and methods. Spring has even support for domain based
security. It allows to check for an object returned by a method, that
the user has a specified right on that object class. The information
about the access right is stored in a pretty simple manner. The
object needs to have an id, think of the id of domain objects in Java
Persistence or Hibernate. The class, the id, the user and his access
rights (read, write, delete etc) are stored in a database. A method
interceptor checks if a method returns an object with access
restrictions.

These security solutions are very complete but in a lot of use
cases just to much. A simpler approach to security is explained on
the following website
<http://blogs.sun.com/enterprisetechtips/entry/improving_jsf_security_configuration_with>
It uses a global action listener and a custom navigation handler
to integrate security. The action listener is called before an action
method is executed. It checks if the user has the required roles to
access the method. The required roles can be specified using an
annotation on the action method.

  @SecurityRoles("customer-admin-adv, root")
  public String delete() {
    System.out.println("I'm a protected method!");
    return "delete-customer";
  }

I liked this approach as it is very simple and just does the job.

How do I do …?

You will find the source code of the following examples in the
provided howto project.

Navigation

JSF 2 has a number of improvements considering navigation. This
chapter assumes that you use Facelets (XHTML) as view technology. It
is the default in JSF 2.
The simplest form to have a link from a page to the page
navigationTarget.xhtml is the following link.

 <h:link outcome="navigationTarget" value="Navigation samples"/>

It renders the following XHTML link.

 <a href="/howto/faces/navigationTarget.xhtml">Navigation samples</a>

There is no need to configure navigation rules in the faces-config
for this use case.
You can easily add a parameter to the link.

 <h:link outcome="navigationTarget" value="Navigation samples">
  <f:param name="id" value="4711"/>
 </h:link>

The rendered link included the param as normal request parameter.

 <a href="/howto/faces/navigationTarget.xhtml?id=4711">Navigation samples</a>

The value attribute can be an expression as well. Here is an example
of a list of articles. We print the list and create a link with the
id of an article as parameter.

 <h:dataTable value="#{navigation.articles}" var="article">
  <h:column><f:facet name="Edit"/>
    <h:link outcome="navigationTarget" value="Edit #{article.id}">
      <f:param name="id" value="#{article.id}"/>
    </h:link>
  </h:column>
</h:dataTable>

Using the parameter in the target page was less beautiful in JSF 1.×.
You had to extract it from the request and convert it to the type
you need.

 public Article getArticle(){
  ExternalContext context =
    FacesContext.getCurrentInstance().getExternalContext();
  Integer id = Integer.parseInt(context.getRequestParameterMap().get("id"));
  return articleService.findById(id);
 }

Now, you can use the tag f:metadata in the target page to write the
parameter into a managed bean property. Let’s have a look at a page
showing details of our domain object Article . The page is
called using a link with a parameter.

http://localhost:8080/howto/faces/navigationTargetArticle.xhtml?id=1

We define that the parameter should be written to the id property
of the managed bean articleBean. In addition we define error
messages in case the id is missing or cannot be converted. The most
interesting item is the f:event . It executes an action
listener to be called. In that case it is called before the view is
rendered and allows to load the article before you start to render
the page. This is an innovation in JSF 2.

 <f:metadata>
  <f:viewParam id="id" name="id" value="#{articleBean.id}"
    required="true"
    requiredMessage="You did not specify an id. (The id parameter is missing)"
    converterMessage="Invalid id. (The id parameter is not a number)"
    validatorMessage="Invalid id. (The id parameter is not a positive number)">
    <f:validateLongRange minimum="1"/>
  </f:viewParam>
  <f:event type="preRenderView" listener="#{articleBean.load}"/>
 </f:metadata>

You can use the f:metadata for a different purpose as well. If you
want to add a parameter to all links of the page, you can use the
following approach. First you create a metadata entry in your page.
You can place it right at the beginning of the page.

 <f:metadata>
  <f:viewParam id="id" name="id" value="4711"/>
 </f:metadata>

If a link should include those params, you add
includeViewParams=“true” to the link and the
parameter will be attached.

 <h:link outcome="navigationTarget" includeViewParams="true" value="Navigation with param (success)"/>

Instead of referencing a target page directly in a GET request you
can make use of navigation rules. These are configured in the
faces-config.xml. If a navigation rule exist for a page, the
outcome attribute of a h:link will no longer be
interpreted as page name but as outcome of the navigation rule.
The link looks pretty much the same,
what we have seen already.

 <h:link outcome="foo" value="Navigation sample"/>

The faces-confix.xml has now a navigation rule for the page
navigation.xhtml. The outcome value foo will
send the user to the page /navigationTarget.xhtml.

<faces-config ...>
...
<navigation-rule>
    <from-view-id>/navigation.xhtml</from-view-id>
  <navigation-case>
      <from-outcome>foo</from-outcome>
      <to-view-id>/navigationTarget.xhtml</to-view-id>
    </navigation-case>
  </navigation-rule>
</faces-config>

The rendered link looks like

Navigation sample

Traditional navigation control

The h:commandLink or the
h:commandButton are both nested inside of a form and ** submit
a form with a POST request. The navigation which happens after a
click is defined by navigation rules and optionally by the return
value (alias: outcome) of an action method. I will show a use case
without an action method first, then we are going to have a look at
the action method.

Both components provide an action
attribute. It can be set to a simple String value. In that case it
has the same meaning as the outcome attribute of a *h:link,

it is used as from-outcome value in a navigation rule.

<h:form>
  <h:commandLink action="bar" value="Navigation with POST"/>
</h:form>

With JSF 2 the navigation rule is optional. By default JSF will try
to find a page named /bar.xhtml. In our case, we use a
navigation rule that will render the page navigationTarget.xhtml.

 <navigation-rule>
  <from-view-id>/navigation.xhtml</from-view-id>
  <navigation-case>
    <from-outcome>bar</from-outcome>
    <to-view-id>/navigationTarget.xhtml</to-view-id>
  </navigation-case>
 </navigation-rule>

If you want to reach the page using a HTTP Redirect, then you add the
following tag to the navigation rule.

 <navigation-case>
  <from-outcome>bar</from-outcome>
  <to-view-id>/navigationTarget.xhtml</to-view-id>
  <redirect/>
 </navigation-case>

If the current page has view parameters then they can be added to the
Redirect URL as well. Just add the attribute include-view-params.

This is useful for example if you want to make use of
Redirect-on-Post pattern. You visit the page *editArticle?id=1,

send a Post which saves your input and Redirect visiting the page
editArticle?id=1 again with a normal GET request. If you
press Reload in your browser, it won’t ask to confirm the
reposting of values.
The final example will navigate to a
page depending on the outcome of an action method. The command link
(you may use a commandButton as well), reference an action method of
a managed bean. When clicking the link a POST request is send and the
action method of a managed bean is called.

 <h:form>
  <h:commandLink action="#{navigation.hello}" value="Navigation with redirect"/>
 </h:form>

Managed beans can be configured in the faces-config.xml or
since JSF 2 with the @ManagedBean annotation. The action
method returns ‘success’.

package de.laliluna.howto.beans;
import javax.faces.bean.ManagedBean;
@ManagedBean
public class Navigation {
  public String hello() {
    System.out.print("Entering hello");
    return "success";
  }
}

The ‘success’ value is used in the navigation case to decide that
we navigate now to the page navigationTarget.xhtml.

 <navigation-case>
  <from-outcome>success</from-outcome>
  <to-view-id>/navigationTarget.xhtml</to-view-id>
 </navigation-case>

If you have multiple action methods with the same outcome values, you
can add the action method as additional criteria. The following rule
is only valid for outcome values of the hello-action.

 <navigation-case>
  <from-action>#{navigation.hello}</from-action>
  <from-outcome>success</from-outcome>
  <to-view-id>/navigationTarget.xhtml</to-view-id>
 </navigation-case>

Friendly URLs

Friendly URLs are search engine and human eyes friendly. The
concept has its origin in RESTFUL applications. These applications
use so called meaningful URLs.
Here is a sample URL for a page showing a list of books

http://localhost:8080/books

And a sample URL for a page showing book with id 12345

http://localhost:8080/books/12345

or
http://localhost:8080/book/12345

In addition you may add a suffix to the URL to get the content in
different format.

 
  http://localhost:8080/book/12345.html // as HTML
  http://localhost:8080/book/12345.pdf // as PDF
  http://localhost:8080/book/12345.xml // as XML

JSF 2 supports now bookmarkable URL. We have seen in the last chapter
that you can add parameters to the URL. This is a major step forward
but today Java based frameworks like Stripes, Tapestry, Wicket and
more or less all Ruby based frameworks like Rails, Sinatra, Ramaze
etc support nice URL.

There is a discussion to support JSR-311 in JSF 2 but the current
status looks like as it won’t be supported directly. For JSF 1.x you
might have a look at <https://restfaces.dev.java.net/>
which provides support for some of the REST concepts. I would like to
show you how to use the extension points of JSF to get this
functionality.

We are going to extend JSF to be able to use URLs like
http://localhost:8080/book/12345
or
http://localhost:8080/books.

First, we will extend the view resolution to let JSF find the page to
render. Second, we will create a component extending the view
parameter. The component can be used in the f:metadata section to
write the parameter included with the URL directly to a managed bean.
If a page with the following snippet is called with an URL like
/navigationTargetArticle/1704, it will write 1704 into
the id property of articleBean.

 <f:metadata>
  <l:urlParam from="/navigationTargetArticle/$$" value="#{articleBean.id}"/>
  <f:event type="preRenderView" listener="#{articleBean.load}"/>
 </f:metadata>

The central element of a JSF 2 application is the Application
class, which can be configured from the faces-config.xml . The
resolution of a view happens during the RestoreViewPhase phase.
The class RestoreViewPhase uses a view handler to determine
the viewId. The view handler is a property of the application and can
be overridden with a custom implementation.
Just create a class FriendlyUrlViewHandler and configure
it in the faces-config.xml

 public class FriendlyUrlViewHandler extends MultiViewHandler {}

 <faces-config ...>
  <application>
    <view-handler>de.laliluna.howto.application.FriendlyUrlViewHandler</view-handler>
  </application>
 ...

The method derivePhysicalViewId is
called to check if a view actually exists. A URL /books/foo could
point to a view /books/foo.xhtml or /books.xhtml with parameter foo.

protected String derivePhysicalViewId(FacesContext ctx, String rawViewId, boolean checkPhysical) {
  if (rawViewId != null) {
    String mapping = Util.getFacesMapping(ctx);
    String viewId;
    if (mapping != null) {
      if (!Util.isPrefixMapped(mapping)) {
        viewId = convertViewId(ctx, rawViewId);
        return checkExistence(ctx, viewId);
      } else {
        List<String> possibleViewIds = analyser.analyse(rawViewId);
        if (possibleViewIds == null) {
          possibleViewIds = Arrays.asList(rawViewId);
        }
        for (String path : possibleViewIds) {
          viewId = normalizeRequestURI(path, mapping);
          if (viewId.equals(mapping)) {
            // The request was to the FacesServlet only - no
            // path info
            // on some containers this causes a recursion in the
            // RequestDispatcher and the request appears to hang.
            // If this is detected, return status 404
            send404Error(ctx);
          }
          viewId = checkExistence(ctx, viewId);
          if (viewId != null) {
            return viewId;
          }
        }
      }
    }
  }
  return rawViewId;
}

The code for the UrlAnalyser class can be found in the
provided source code. Now, we can input links like
http://localhost:8080/faces/home
to call the home.xhtml. The next step is to create a component which
writes the URL value into a managed bean. The class *UIUrlParam

has a parameter from , which expects a text that starts
with the url and has a $$ somewhere to indicate the value. This
String is converted into a regular expression.

package de.laliluna.howto.components;
import com.sun.faces.util.FacesLogger;
import java.util.logging.Logger;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
import javax.faces.component.UIViewParameter;
import javax.faces.context.FacesContext;
public class UIUrlParam extends UIViewParameter {
  private static final Logger logger = FacesLogger.APPLICATION.getLogger();
  private String from;
  private Pattern pattern;
  private String rawValue;
  public static final String COMPONENT_TYPE = "de.laliluna.howto.components.UrlParameter";
  public UIUrlParam() {
    super(); // will set the renderer to null, as this component is not rendered
  }

  public String getFrom() {
    return from;
  }
  public void setFrom(String from) {
    this.from = from;
    String regex = from.replace("/", "\/").replaceFirst("\$\$", "([^/]?)");
    pattern = Pattern.compile(regex);
  }
  @Override
  public void decode(FacesContext context) {
    if (context == null) {
      throw new NullPointerException();
    }
    String path = context.getExternalContext().getRequestPathInfo();
    String viewId = context.getViewRoot().getViewId();
    if (viewId.equals(path)) {
    } else {
      Matcher matcher = pattern.matcher(path);
      if (matcher.find() && matcher.groupCount() > 0) {
        String param = matcher.group(1);
        if (param != null) {
          setSubmittedValue(param);
        }
      }
    }
    rawValue = (String) getSubmittedValue();
    setValid(true);
  }
  @Override
  public String getStringValue(FacesContext context) {
    String result = null;
    if (hasValueExpression()) {
      result = getStringValueFromModel(context);
    } else {
      result = (null != rawValue) ? rawValue : (String) getValue();
    }
    return result;
  }
  private boolean hasValueExpression() {
    return null != getValueExpression("value");
  }
}

The component doesn’t require a renderer. Now, we need to make JSF
aware of the component. We can either mark the component class with
the @FacesComponent(value =
“de.laliluna.howto.components.UrlParameter”) annotation
or configure it in the faces-config.xml

<faces-config ...>
...
<component>
    <component-type>
      de.laliluna.howto.components.UrlParameter
    </component-type>
    <component-class>
      de.laliluna.howto.components.UIUrlParam
    </component-class>
  </component>
</faces-config>

In addition we need to create a tag library. It is an xml file ending
with .taglib.xml

<!DOCTYPE facelet-taglib PUBLIC
  "-//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN"
  "http://java.sun.com/dtd/facelet-taglib_1_0.dtd">
<facelet-taglib>
  <namespace>http://www.laliluna.de/components/sample</namespace>
  <tag>
    <tag-name>urlParam</tag-name>
    <component>
      <component-type>de.laliluna.howto.components.UrlParameter</component-type>
    </component>
  </tag>
</facelet-taglib>

Please keep in mind that this is a working but simple implementation.
You may enhance it to your needs.
There is a more advanced extension as well to achieve nice URLs.
Have a look at <http://ocpsoft.com/prettyfaces/>,
which provides friendly URL functionality for JSF 1.x and JSF 2.

Templates

If you decided to use Facelets to
create pages (the recommend approach), then you have a flexible
template engine in your hand. The following is a template with two
place holders title and body specified with the
<ui:insert> tag. Both place holder have a default
content. The default content for body is Welcome.

 <?xml version='1.0' encoding='UTF-8' ?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:h="http://java.sun.com/jsf/html">
  <h:head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Facelets - Template Example</title>
  </h:head>
  <h:outputStylesheet library="css" name="default.css"/>
  <body>
    <h1>
      <ui:insert name="title">Howto Samples</ui:insert>
    </h1>
    <h:link outcome="home" value="Back to Home Page"/>
      <p>
        <ui:insert name="body">Welcome</ui:insert>
      </p>
  </body>
</html>

Below you can see a page using the
template. The <ui:define> tags define the content
which is inserted at the place holder location of the template.

<?xml version='1.0' encoding='UTF-8' ?>
<body xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core">
<ui:composition template="/template.xhtml">
  <ui:define name="title">
    Ajax Samples
  </ui:define>
  <ui:define name="body">
    <div>#{ajaxBean.time}</div>
  </ui:define>
</ui:composition>
</body>

An interesting feature is to decorate small fragments of a page with
a template.

<ui:decorate template="/layout.xhtml">
  <ui:define name="content">
  Foo bar
  </ui:define>
</ui:decorate>
.. more page

Using an expression, you can even localize or customize your
templates. The following code snippets decorates the code with a
template, which is chosen dependent on the users language.

<ui:decorate template="templatePart#{facesContext.viewRoot.locale}.xhtml">
  <ui:define name="titel">The legend</ui:define>
  <ui:define name="content">Content of the fieldset</ui:define>
</ui:decorate>

The Facelets template support is quite powerful and flexible and a
good reason not to create your pages based on JSP technology.

Forms and validation

Input handling
Input handling is a team game of pages, EL-expressions and managed
beans. A page contains a form with EL-expressions.

<h:form>
  <h:inputText id="name" value="#{inputBean.name}"/>
  <h:commandButton actionListener="#{inputBean.save}" value="Save"/>
</h:form>

When the form is submitted, the input for name is written into the
managed bean inputBean into the field name. Below you
can see an extract of the inputBean.

@ManagedBean @RequestScoped
public class InputBean {
  private String name;
  
  public String getName() {
    return name;
  }
  public void setName(String name) {
    this.name = name;
  }
...  
}

There is a limitation considering nested objects. Most frameworks
instantiate nested objects automatically. Below you can see the
address as example. JSF doesn’t instantiate it for you and
requires that there is a constructor doing the job.

<h:form>
  <h:inputText id="name" value="#{inputBean.address.name}"/>
  <h:commandButton actionListener="#{inputBean.save}" value="Save"/>
</h:form>

If you add a constructor to the inputBean, the address will
always be instantiated, even if there are no values for the address.
In my opinion, this is really an annoyance as this might have side
effects, depending on the used technologies and requires unnecessary
code for nestest structures.

 public InputBean() {
  address = new Address();
 }

Validation
The validation approach of JSF is
flexible and can be customized. The only limitation I found is the
lack of a real client side validation. JSF 2 allows to validate a
field on jumping to the next field. It sends a request to the
server, which will do a partial of processing of this field only.
This is of course better than waiting for a form submit but it would
be much more efficient to drop the server request completely. Server
validation should only take place for security reason in case
somebody has disabled JavaScript.

There are two choices to implement
validations: the classic JSF validation tags directly in the page or
using bean validation (JSR 303). The bean validation is a framework
for validation and provides a consistent approach for input
validation, validation in the persistence layer or any other layer.
Validations can be defined using annotations in the managed bean or
the domain classes. If you prefer an external definition, then you
can use an XML file, validation.xml.

The classic approach has the
advantage that you can validate the same domain class differently in
different dialogs, which requires a very verbose group validation
configuration, if you use bean validation. The second approach has
the advantage that the same validations can be used for JSF, for a
webservice interface or just in the persistence layer to guaranty
consistency of the data. Below you can see an example using page
based validation.

<h:inputText id="name" value="#{inputBean.address.name}" required="true">
  <f:validateLength minimum="3" maximum="6" />
</h:inputText>

If you want to use annotation based validation, you will need an
implementation of the bean validation JSR. The reference
implementation is Hibernate 4.×. The configuration is pretty simple.
Just add the libraries hibernate-validator-4.0.0.GA.jar and
validation-api-1.0.0.GA.jar to your application.

In JSF 2 it is no longer to required to define the following
parameter in the web.xml. JSF 1.x needs the parameter for bean
validation to work. Otherwise empty values are not validated.

javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL

That’s all you need to do. JSF will
detect the availability of the validation libraries and check for
annotations in managed bean or domain models. I added the annotations
to the address class which is referenced by the managed bean
inputBean.

import javax.validation.constraints.NotNull;
import javax.validation.constraints.Size;
import java.util.Date;
public class Address {
  private Integer id;
  
  @NotNull
  private String name;
  
  @NotNull @Size(min = 2, max = 10)
  private String street;

Here is the inputBean class.

@ManagedBean @RequestScoped
public class InputBean {
  
  private Address address;
  
  public InputBean() {
    address = new Address();
  }
  public Address getAddress() {
    return address;
  }
  public void setAddress(Address address) {
    this.address = address;
  }
  ...
}

Bean Validation supports a feature called validation groups. It
allows to check only validations for a specific group instead of all
validations defined by annotations. This is useful if a managed bean
or a domain class is filled only partly by a dialog.
First you need to define that a input
field is validated with group validations. The following input field
triggers validations of the group
de.laliluna.InputBeanEmailValidation.

<h:inputText id="email" value="#{inputBean.address.email}">
  <f:validateBean validationGroups="de.laliluna.InputBeanEmailValidation"/>
</h:inputText>

The Address class has a field email having a validation
annotation.

@NotNull(groups = {InputBeanEmailValidation.class})
private String email;

You will find articles using a String as validation group. This is no
longer correct. The final draft of the bean validation specification
uses classes or interfaces as group names. In the worst case, you
need to define an empty interface. The group feature is a nice idea
to bring flexibility to annotation based validation but the idea to
use class names as groups is a real show stopper. Imagine you have 15
input fields and every field has the validation group tag. JSF
developers are likely in danger to get the nick name ‘copy pasties’.

I had some minor issues with Hibernate
Validation. The validation messages are not yet properly translated.
As a consequence you will have to provide your own messages. Another
problem was that Hibernate validation looks for custom messages in a
property file starting with ValidationMessages in the root of the
classpath (in web apps: WEB-INF/classes). It does currently not check
for a default property file as JSF does.
ValidationMessages.properties are not recognized but only
ValidationMessages_en.properties. The \_en suffix can be
replaced with the supported languages.

Another issues was that the
@Size validation can be used for the length of a String, the
size of a collection/map/array. The error message is saying that the
size is not correct which is a bad expression if a String is to short
or to long. If you specify only the min size, the error message is
telling you that the size has to be between 3 and 2147483647. This is
probably why the Hibernate implementation of the Bean Validation
Standard adds extensions like @Min and @Max.

Custom validation

JSF validation inside of the pages and bean validation can both be
customized. I will show you you to implement a custom validator which
checks if an email is an internal email. For my case, internal emails
end with ‘@laliluna.de’
JSF validator
You need to create a class implementing the Validator interface. If the validation fails, you should throw a
ValidatorException . The class MessageFactory is a class
of mine, which hides the access to resource bundles. Have a look in
the provided source code for details.

@FacesValidator("companyEmail")
public class CompanyEmailValidator implements Validator {
  public static final String VALIDATOR_ID = "companyEmail";
  
  public void validate(FacesContext facesContext, UIComponent uiComponent, Object value) throws ValidatorException {
    String email = (String) value;
    if (email != null) {
      email = email.toLowerCase();
      if (email.endsWith("@laliluna.de"))
        return;
    }
    throw new ValidatorException(MessageFactory.getMessage(facesContext, "validation_company_email"));
  }
}

The validator is identified by an ID. It is referenced when using the
validator:

<h:inputText id="email" value="#{inputBean.address.email}">
  <f:validator validatorId="companyEmail"/>
</h:inputText>

JSF is informed about a custom validator either by adding the
annotation @FacesValidator or by configuring the validator in
the faces-config.xml.

 <validator>
  <validator-id>companyEmail</validator-id>
  <validator-class>de.laliluna.howto.components.CompanyEmailValidator</validator-class>
 </validator>

Validators with parameters should implement the PartialStateHolder interface. Have a look in the
default length validator to see how a validator with parameter looks
like.

Bean Validation Custom Validator
There are three steps to create a custom validator

An annotation to configure the validation for a field, sample @CustomEmail
The Validation class
Entries in the resource bundle for validation error messages

An annotation implementation looks like an interface with some
annotations. It is actually pretty simple. The annotation defines
which message key to use in case an error message needs to be looked
up in a resource bundle. This is specified with message. The
@Constraint annotation defines which class is implementing the
validator. The field groups allows to specify group
validations.

@Target({METHOD, FIELD, ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = CompanyEmailValidator2.class)
@Documented
public @interface CompanyEmail {
  String message() default "{de.laliluna.howto.components.validation.companyemail}";
  
  Class<?>[] groups() default {};
  
  Class<? extends Payload>[] payload() default {};
}

The validation class needs to implement the interface *
ConstraintValidator.* It has two generic parameters. The first one
( CompanyEmail ) specifies that this is a validator for the
annotation CompanyEmail. The second one String specifies
that the input value is a String.

public class CompanyEmailValidator2 implements ConstraintValidator<CompanyEmail,String>{
  public void initialize(CompanyEmail constraintAnnotation) {
  }
  public boolean isValid(String value, ConstraintValidatorContext context) {
    if(value == null) // assume that the user uses @NotNull to validate not null
    return true;
    value = value.toLowerCase();
    return value.endsWith("@laliluna.de");
  }
}

The isValid method can return false to indicate that the
validation failed but may as well throw an exception. Finally, we add
the validation error message to the resource bundle
ValidationMessages. As already mentioned, this is the place
where Hibernate Validator looks for custom messages. Here is an
extract of ValidationMessages_en.properties

de.laliluna.howto.components.validation.companyemail=The email is not …

To summarize, customized validation is
quite simple to achieve in JSF both with the traditional approach of
JSF or using bean validation.

Have a look at the documentation of
Hibernate Validation on www.hibernate.org
to get more information on bean validation. The documentation is
quite good.

Cross field validation
Cross field validation means that you compare two or more fields
with another. Think of a date range and you want to validate that the
start date is before the end date.
The validation in JSF happens as part of the validation phase,
which executes validations per component. As a consequence, there is
no phase in the lifecycle which can be used for cross field
validation. The workaround to achieve cross field validation is to
specify a custom validation method for the last input field. There
are two notable attributes in this page. The first attribute is
binding . It specifies that the input component should be
injected into the managed bean which allows to access the input value
before it is written into the field from. The second attribute
is validator. It specifies a custom validation method in a
managed bean.

<h:inputText id="from" value="#{inputBeanCross.from}" binding="#{inputBeanCross.fromInput}"/>
<h:inputText id="to" value="#{inputBeanCross.to}" validator="#{inputBeanCross.validateMe}"/>

The validateMe method in the managed bean, extracts the value
from the component and compares both values. It throws an exception
in case the validation fails. This is the same behaviour as a normal
validator.

public class InputBeanCross {
  private Date from;
  // binding for the from input to access the value before it is written to the from field
  private UIInput fromInput;
  private Date to;
  
  public void validateMe(FacesContext context, UIComponent component, Object value) throws ValidatorException  {
    if(value==null)
      return;
    Date fromDate = (Date) fromInput.getValue();
    Date toDate = (Date) value;
      if (fromDate == null) {
      FacesMessage message = MessageFactory.getMessage(context, "validation_from_null");
      // add the error message to the from field
      context.addMessage(fromInput.getClientId(context), message);
      fromInput.setValid(false);
      // add the error message to the to field
      throw new ValidatorException(message);
    }
    if (toDate.before(fromDate)){
      FacesMessage message = MessageFactory.getMessage(context, "validation_from_to");
      // add the error message to the from field
      context.addMessage(fromInput.getClientId(context), message);
      fromInput.setValid(false);
      // add the error message to the to field
      throw new ValidatorException(message);
    }
  }

By default, the implementation will only display an error message at
the to field. The from field is not marked. As I wanted to show the
error message next to both input fields, I added the following lines
to mark the from field as invalid.

context.addMessage(fromInput.getClientId(context), message);
fromInput.setValid(false);

I wouldn’t call cross field validation very elegant but you achieve
it with the provided means.

Advanced converting

Converting for standard Java types works out of the box. This
includes Java 5 Enums which required a custom converter prior to JSF
2. For date fields you need to specify the date format. The following
code snippet shows an input field which uses a short date input. The
formatter is based on the Java date formatter.

<h:inputText id="from" value="#{inputBeanCross.from}"
  <f:convertDateTime dateStyle="short" type="date"/>
</h:inputText>

You can use the same converter to display a sample date to the user.

<h:outputText value="#{inputBean.sampleDate}">
  <f:convertDateTime dateStyle="short" type="date"/>
</h:outputText>

Customize converting of input

You can easily write a customized converter. A converter provides
two methods, one converting an input String from the browser to date
target type and one to convert the type into a String to display it
in an input field. Here is a sample converting a phone number in the
format ‘countryCode / prefix / code’ to an instance of Phone.

@FacesConverter(forClass = Phone.class)
public class PhoneConverter implements Converter {
  /**
   * Actually obsolete as we registered the converter in the faces-config by type
   */
  public static final String CONVERTER_ID = "de.laliluna.Phone";
  public Object getAsObject(FacesContext facesContext, UIComponent uiComponent, String rawValue) {
    Phone phone = null;
    if (rawValue != null && rawValue.length()>0) {
      String parts[] = rawValue.split("/");
      if (parts.length != 3)
        throw new ConverterException(MessageFactory.getMessage(facesContext,
            "phoneconverter-bad-string", new Phone("49", "123", "456789")));
      phone = new Phone(parts[0], parts[1], parts[2]);
    }
    return phone;
  }
  public String getAsString(FacesContext facesContext, UIComponent uiComponent, Object value) {
    // We are friendly and return at least an empty String
    String stringValue = "";
    if (value != null) {
      // Default components check if the value is a String and return it as it is
      if (value instanceof String)
        stringValue = (String) value;
      else if (value instanceof Phone) {
        Phone phoneValue = (Phone) value;
        stringValue = String.format("%s/%s/%s", phoneValue.getCountryCode(), phoneValue.getAreaPrefix(),
            phoneValue.getCode());
      } else
        throw new ConverterException(MessageFactory.getMessage(facesContext,"phoneconverter-bad-phone"));
    }
    return stringValue;
  }
}

The configuration of your converter can be done with an annotation or
inside of the faces-config.xml.

<converter>
  <converter-for-class>de.laliluna.howto.model.Phone</converter-for-class>
  <converter-class>de.laliluna.howto.components.PhoneConverter</converter-class>
</converter>

If you configure the converter for a class, as done in our example,
the converter is automatically chosen if the target type is an
instance of Phone.
If the target type is ambiguous, you can reference a converter
using an id.

The id can be specified in the annotation

@FacesConverter(value ="phoneConverter")
public class PhoneConverter implements Converter {

and in the faces-config.xml

<converter>
  <converter-id>phoneConverter</converter-id>
  <converter-class>de.laliluna.howto.components.PhoneConverter</converter-class>
</converter>

Id based and type based configurations are mutual exclusive.
The custom converter support of JSF is
flexible and simple to create. The only thing, I wondered about, was
that the converter interface wasn’t migrated to a generic
implementation in order to avoid type casts.

Common dialog tasks

Are more complex input widgets provided like calendars or tree tables

A central idea of JSF is that other companies can provide their
own component library. The core component of JSF are pretty simple
and reflect the input fields available in HTML. By default a JSF
implementation does not provide any complex input widget, but you
have a number of options.

The first option is to stay with the standard and not use any
component collections. There is a good reason to do this, as
components themselves are not standardized and most collections are
driven by a single vendor. You can still achieve advanced input
widgets using JavaScript. JavaScript can transform simple HTML tags
into an animated menu, tree structure etc. You may have a look at my
IT book evaluation portal <http://www.bibabook.de>
to see an accordion menu in action. I used the Jquery UI Javascript
library to achieve the effect. There are a number of powerful
JavaScript frameworks like Yahoo UI or the just named Jquery UI.

If you don’t want every developer of your team write JavaScript
code you may hide the JavaScript in a composite component. JSF 2
facilitates to add JavaScript behaviour to existing components, which
turns this approach into a viable option.

The second option is to use a component library. Mojarra provides
a new component library for JSF 2, which is based on Yahoo UI
JavaScript widgets. It is called Mojarra Scales. Sun had a component
collection named Woodstock which will be discontinued. Sun recommends
to use Icefaces instead for new projects. MyFaces provides two
component collections. One (Trinidad) was donated by Oracle a couple
of years ago, one is the original MyFaces collection. Oracle still
has its own component suite, called Oracle ADF Rich faces and JBoss
provides the Richfaces component library. Finally, there is
PrimeFaces which is less popular as the others but known to be very
fast. Yes, component libraries have an impact on application
performance.

A probably not complete overview about those and other component
collections can be found here:
<http://www.jsfmatrix.net/>

I added links to some of the components collections to the
reference below. Please, check carefully if the component collection
is still supported.

Is there a simple way to iterate through collections?

The UIRepeat component is meant to be used.

<ui:repeat var="item" value="#{inputBeanCross.articles}">
  <div><h:outputText value="#{item.name}"/></div>
</ui:repeat>

How do I hide a part of the page depending on a condition?

Every component supports a rendered attribute, which accept any
kind of EL expressions.

<h:inputText value="#{inputBean.address.phone}" rendered="#{inputBean.address.hasPhone}"/>

How do I print a sorting table?

You could use either <ui:repeat> or <ui:dataTable> to render a table. Inside of the table you add ajax enabled forms
to submit the sort criteria and call the sort method. I added a parameter to every link and used the <f:viewParam id=“id”
name=“sortCriteria” value=“#{ajaxTable.sortCriteria}”/> to write the parameter into the managed beans sortCriteria field. The action listener calls the sort method.

<?xml version='1.0' encoding='UTF-8' ?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:h="http://java.sun.com/jsf/html">
  <h:head>
    <title>Facelets - Template Example</title>
  </h:head>
  <body>
<f:metadata>
  <f:viewParam id="id" name="sortCriteria" value="#{ajaxTable.sortCriteria}"/>
</f:metadata>
<h:form>
  <h:dataTable id="table" value="#{ajaxTable.articles}" var="a">
    <h:column>
      <f:facet name="header">
        <h:commandLink actionListener="#{ajaxTable.sort}" value="Id">
          <f:ajax render="table"/><f:param name="sortCriteria" value="id"/>           
        </h:commandLink>
      </f:facet>
      <h:outputText value="#{a.id}"/>
    </h:column>
  </h:dataTable>
</h:form>
</body>
</html>

If your application server does already support the new EL
modification to JSR 245 (for example Glassfish v3, then you can just
pass a value to a method using the new EL expression.

<h:commandLink actionListener="#{ajaxTable.sort('id')}" value="Id">
  <f:ajax render="table"/><f:param name="sortCriteria" value="id"/>
</h:commandLink>

Most component libraries provide grid or table components as well.

Multi row input and indexed properties

Creating a table from a list of objects is on the first look
pretty simple. You create a managed bean which provides a List of
articles.

public class AjaxTable {
  public AjaxTable() {
    editArticles =  ServiceFactoryImp.getInstance().getService(ArticleService.class).findAll();
  }  
  
  public List<Article> getEditArticles() {
    return editArticles;
  }
  
  public String save() {
    ArticleService service = 
        ServiceFactoryImp.getInstance().getService(ArticleService.class);
    for (Article article : editArticles) {
      logger.debug("Create or update {}", article);
      service.update(article);
    }
    return "ajaxTable?faces-redirect=true";
  }
...

and use it with a <h:dataTable>

<h:form>
  <h:dataTable id="table" value="#{ajaxTable.editArticles}" var="a">
    <h:column>
      <f:facet name="header">
        Id
      </f:facet>
      <h:outputText value="#{a.id}"/>
    </h:column>
    <h:column>
      <f:facet name="header">
          Name
      </f:facet>
      <h:inputText id="name" value="#{a.name}"/>
      <h:message for="name"/>
    </h:column>
    <h:column>
      <f:facet name="header">
        Description
      </f:facet>
      <h:inputTextarea rows="3" cols="40" value="#{a.description}"/>
    </h:column>
  </h:dataTable>
  <h:commandButton value="Save" action="#{ajaxTable.save}"/>
</h:form>

The problem are only visible on the second look. When processing the
form submit, JSF will not create a list of articles from the input
form, but expects that the list is already there. The constructor
initializes the editArticles not only for the rendering but as well
for the input processing. As long as we know which and how many
articles are being edited, this is no problem but it becomes a
problem, if we allow to add empty articles. In that case we need to
put the managed bean into the session scope with the side effect that
we cannot use the same dialog in two browser windows.

The reason why other frameworks have
less problems with such a use case is that the binding used to print
a list of objects is not correlated with the handling of the input.
The submit of such a table of data will create the target objects on
the fly.

Message resources and internationalization

JSF supports the common approach to
store messages in property files. A property file with the suffix
‘_en’ is used for an English local and the property file with a ‘_de’
suffix is used for German locale. If you distinguish British English
and American English, then you can add the country to the suffix like
‘_en_GB’.

If you support English and German, then
you might have the following resource bundle files

messages.properties
messages_en.properties
messages_de.properties

The first resource bundle is optional
and contains the default texts. It is used if a message cannot be
found in the other bundles. It might be simpler, if you leave out the
english resource bundle, assuming that English is your default
language, and store the English texts in the default bundle and drop
the messages_en.properties file.
This is how a resource bundle looks
like

address_moved_label=Move-in date address_phone_label=Phone number select_label=Select

The configuration of a resource bundle is simple. You can load it
globally for all views or for a specific view.
A global configuration happens inside
of the faces-config.xml. The following configuration will load
property files like messages.properties, messages_de.properties from
the package de.laliluna.howto and make it available as
request variable with the key m.

<resource-bundle>
  <base-name>de.laliluna.howto.messages</base-name>
  <var>m</var>
</resource-bundle>

Inside of a page you can now use it with an EL-expression.

#{text.bar}
<h:outputLabel for="foo" value="#{text.bar}"/>

A nice option is to use a message with place holder as in Java class
MessageFormat. The following are the entries in the resource bundle.

notfound={0} not found user=User

The following tag prints the text ‘User not found’

<h:outputFormat value="#{text.notfound}">
  <f:param value="#{text.user}"/>
</h:outputFormat>

If you want to use a resource bundle
only in a limited number of views, then you can explicitly load a
resource bundle into a view. The following tag inside of a page,
makes the resource bundle available under the key text.

Programmatically accessing resource bundles

You can access the global bundle
messages programmatically as well.

public String getHello(){
  FacesContext context = FacesContext.getCurrentInstance();
  ResourceBundle bundle = context.getApplication().getResourceBundle(context, "m");
  return bundle.getString("hello");
}

If you want to access another resource bundle, you need to follow a
slightly different approach.

public String getGoodBye(){
  FacesContext context = FacesContext.getCurrentInstance();
  ResourceBundle bundle = ResourceBundle.getBundle("de.laliluna.howto.anotherbundle", context.getViewRoot().getLocale());
  return bundle.getString("goodbye");
}

Configuring Locales

You can see in the last code snippet
that the locale of the user is stored in the root component of a
view. The locale is normal chosen from the browser locales. You can
limit the available choices by configuration in the faces-config.xml .
The following code snippet defines that the en and de are
supported. En is used as default in case the browser has
another locale configured. You should always configure a default
locale or visitors might see a broken page.

<faces-config ...>
  <application>
   <locale-config>
    <default-locale>en</default-locale>
    <supported-locale>de</supported-locale>
  </locale-config>

You can define on a page that it should render in a specific locale.
Below you can see an example with a static value and another one with
a EL-Expression.

<f:view locale="en">
<f:view locale="#{userBean.locale}">

I didn’t like this approach as it requires the EL in all views. It is
in fact poorly documented how to do customize the locale selection.
One thing is important: if you want set the locale in the root
component, then you need to do this before the render phase. I added
a phase listener which determines the locale from a managed bean in
the session scope. This allows to change the locale programmatically.
The following code snippet is an
extract of the class LocaleRenderPhaseListener. The first part
creates an EL-Expression to get the userBean. The last line
sets the locale the locale of the userBean .

public void beforePhase(PhaseEvent phaseEvent) {
  FacesContext context = phaseEvent.getFacesContext();
  Application application = context.getApplication();
  ExpressionFactory factory = application.getExpressionFactory();
  ValueExpression valueExpression = factory.createValueExpression(context.getELContext(),
      "#{userBean}", UserBean.class);
  UserBean userBean = (UserBean) valueExpression.getValue(context.getELContext());
  context.getViewRoot().setLocale(userBean.getLocale());
}

Validation and Error messages

Validation messages are taken from a
message bundle, which is slightly different then the resource bundle,
I explained so far. Before JSF 1.2 only the message bundle were
available.
JSF provides already resource bundle
for converter and validations. If you want to overwrite those values
then you can specify the values in a message bundle and configure it
in the faces-config.xml

<faces-config ...> 
  <application>
   ...
   <message-bundle>
     de.laliluna.howto.customerrors
   </message-bundle>

This is the place where custom validator and converter will look up
messages as well. There is a common approach of validation and
converter errors to provide a short message as default and details in
a key with a \_detail suffix.

myerror=Bad problem myerror_detail=There is no chance to get out of this.

Exception handling

Exception handling has changed and is way better then in JSF 1.×.
First, I will show you the simplest form and then we have a look at
the new options.
This description is mostly taken from
<http://weblogs.java.net/blog/edburns/archive/2009/09/03/dealing-gracefully-viewexpiredexception-jsf2>
The simplest form is to provide a mapping from Exception to error
pages in the web.xml

<error-page>
  <exception-type>java.lang.IllegalArgumentException</exception-type>
  <location>/faces/error.xhtml</location>
</error-page>

JSF stores a number of values in the request which allows to show
more details on the error page. Here is a snippet form my error page.

<h2>You have encountered a system error</h2>
The error message is: #{requestScope['javax.servlet.error.message']}<br>
Below are informations for the system administrators <br>
<textarea rows="20" cols="80" disabled="true"><h:outputText escape="false" value="#{errorBean.stackTrace}"/></textarea>

The managed bean extract the exception from the request and builds a
String from the stacktrace. This example is kept simplistic and you
may improve the method to print nested exceptions or to determine the
root cause.

@ManagedBean
public class ErrorBean {
  private static final String BR = "n";
  
  public String getStackTrace(){
    FacesContext context = FacesContext.getCurrentInstance();
    Map<String,Object> map = context.getExternalContext().getRequestMap();
    Throwable throwable = (Throwable) map.get("javax.servlet.error.exception");
    StringBuilder builder = new StringBuilder();
    builder.append(throwable.getMessage()).append(BR);
    for (StackTraceElement element : throwable.getStackTrace()) {
      builder.append(element).append(BR);
    }
    return builder.toString();
  }
}

If you want to customize the exception handling further, then you can
add your own exception handler and take control over the process.
A custom exception handler is
integrated using by configuring it in the faces-config.xml .

<faces-config ...>
 <factory>
  <exception-handler-factory>
    de.laliluna.howto.application.CustomExceptionHandlerFactory
  </exception-handler-factory>
 </factory>

In fact you specify a factory, which will create your custom
exception handler. In the custom exception handler, we can override
the handle method. My implementation redirects to a special
view page in case of a ViewExpiredException. The following code
iterates over the not handled exceptions and in case it is a
ViewExpireException, deal with it and remove it from the iterator. It
is important to remove the exception or it will be handled multiple
times.

public void handle() throws FacesException {
  Iterator<ExceptionQueuedEvent> iterator = getUnhandledExceptionQueuedEvents().iterator();
  while (iterator.hasNext()) {
    ExceptionQueuedEvent event = iterator.next();
    ExceptionQueuedEventContext context = (ExceptionQueuedEventContext) event.getSource();
    if (context.getException() instanceof ViewExpiredException) {
      ViewExpiredException exception = 
        (ViewExpiredException) context.getException();
      FacesContext fc = FacesContext.getCurrentInstance();
      Map<String, Object> requestMap = fc.getExternalContext().getRequestMap();
      NavigationHandler nav =
          fc.getApplication().getNavigationHandler();
      try {
        // in development mode, we want to show the normal debug screen of facelets
        if(fc.isProjectStage(ProjectStage.Development)){
          fc.getExternalContext().getRequestMap()
            .put("com.sun.faces.error.view", fc.getViewRoot());
          throw new FacesException(context.getException().getMessage(),
             context.getException());
        } else{
        // Push some useful stuff to the request scope for
        // use in the page
        requestMap.put("currentViewId", exception.getViewId());
        nav.handleNavigation(fc, null, "viewexpired");
        fc.renderResponse();
        }
      } finally {
        iterator.remove();
      }
    }
  }
  super.handle();
}

At the time of writing, JSF 2 wrapped
exceptions from action methods and action listener into an
AbortProcessingException. If your managed bean or the business layer
called by the managed bean throw an exception, then it was swallowed.
I assume that this is a bug in the tested version and implemented a
workaround in the custom exception handler. Have a look into the
provided source code. Keep in mind that the version of JSF, I tested,
is not yet stable.

Redirect on post and flash scope

Redirect on post doesn’t work for all use cases. If you want to
make use of the URL parameter for the following request series, then
you won’t have luck.

1. GET /books/edit.xhtml?id=4711
2. POST of input
3. REDIRECT to /books/edit.xhtml?id=4711

At the time of writing JSF 2 didn’t allow to include view
parameters in an input form. This is only possible for a GET request
using the new <link> or <button> tags.

What is possible to do a redirect after a POST request and store
messages and objects in the flash scope. Just in case, you haven’t
read the initial article of this series. It is a scope, which is
inspired by Ruby on Rails. It preservers objects for the next
request, if you do a redirect.
A flash scope was introduced with JSF 2. If you want to print a
message after a redirect, then you can use the following code in an
action method. I used implicit navigation without navigation rules in
the faces-config.xml in this sample.

public String save(){
  FacesContext context = FacesContext.getCurrentInstance();
  context.getExternalContext().getFlash().setKeepMessages(true);
  context.addMessage(null, new FacesMessage("The name was successfully saved "));
  return "article?faces-redirect=true";
}

In addition your can store arbitrary values in the flash scope.

context.getExternalContext().getFlash().put(“foo”,“bar”);

You can access those values using EL-Expressions

#{flash[‘foo’]}

or
#{flash.foo}

or programmatically.

context.getExternalContext().getFlash().get(“foo”);

Conversation context, wizards and workflows

There is no build in support for wizards or workflows. There are a
number of external solutions to solve this problem like Apache
Orchestra, JBoss Seam, Spring WebFlow and in the future the
integration of Web Beans (alias JSR 299, alias Java Dependency
Injection) will provide another option.

In this article, I would like to achieve a wizard using the
provided extension options. We can follow two strategies to do this.
The first is to define a custom scope, which is stored in the session
scope. Inside the custom scope, you could add a wizard using a key
like ‘cart_checkout’. The disadvantage of this approach is that you
cannot have multiple instances of the wizard in different browser
windows.
Recently, I came up with the idea that the browser could
send a window-id as request header and promoted the idea to the
browser vendors. See <http://www.laliluna.de/articles/ideas/>

This would allow to have a wizard with the same key per browser
window. I wrote a plugin for Firefox, which provides the window-id
and are about to write the plugin for Safari and IE. But at the
moment, we have to live with the fact that browsers share the session
across windows.

The second approach is to identify a wizard using an id. This an
approach for example available in JBoss Seam. They call it
conversation scope. This approach requires that the id is part of
every link and every form. If we used the classic JSF approach to
send only POST requests, then this could be hidden more easily but
the bookmarkable URLs of JSF 2 come with the tradeoff that
information like that needs to be in the URL as well. This is why, I
promote the idea of the windows-id.

Finally, let’s start doing it. I will use the second approach,
which identifies the wizard using an id. The following steps are
required to achieve this:

Create a custom scope
Create a custom component to be used to add the id to forms
Leave the custom link component for the reader ;-)
Make sure that the id survives a redirect

Creating a custom scope is demonstrated in the blog of Ryan Lubke.
We need an EL-resolver for our scope. An EL-expressions like #{wizardScope.myBean} is resolved piece by piece. First all
EL-resolvers are asked for the part wizardScope. Once the
scope is resolved, the EL-resolvers are asked to resolve myBean in
the first part, the wizard scope instance. As a consequence, our
EL-resolver needs to resolve the scope itself and beans inside of the
scope.

The following is an extract of the class
WizardScopeResolver. The first method is internal and extracts
the scope from the HTTPSession . The second is doing the
‘normal’ EL resolution.

 private WizardScope getScope(ELContext elContext) {
  CustomFacesContext ctx = CustomFacesContext.getCurrent();
  HttpSession session = (HttpSession) ctx.getExternalContext().getSession(true);
  WizardScopeResolver.WizardScope wizardScope = null;

  synchronized (session.getId()) {
    Map<String, WizardScope> scopes = (Map<String, WizardScopeResolver.WizardScope>) session.getAttribute(
      WizardHelper.WIZARD_SCOPE_KEY);
    if (scopes == null) {
      scopes = new HashMap<String, WizardScope>();
      wizardScope = new WizardScopeResolver.WizardScope();
      scopes.put(ctx.getWizardId(), wizardScope);
      logger.debug("Created wizard scope with id ({})", ctx.getWizardId());
      session.setAttribute(WizardHelper.WIZARD_SCOPE_KEY, scopes);
    } else {
      wizardScope = scopes.get(ctx.getWizardId());
      if (wizardScope == null) {
        wizardScope = new WizardScopeResolver.WizardScope();
        scopes.put(ctx.getWizardId(), wizardScope);
        logger.debug("Created wizard scope with id ({})", ctx.getWizardId());
      }
    }
  }
  return wizardScope;
 }
 public Object getValue(ELContext elContext, Object base, Object property) {
  if (property == null) {
    throw new PropertyNotFoundException("Could not resolve property, as property name is null");
  }
  if (base == null) {
    if (SCOPE_NAME.equals(property.toString())) {
      elContext.setPropertyResolved(true);
      return getScope(elContext);
    } else {
      return lookup(elContext, getScope(elContext), property.toString());
    }
  } else if (base instanceof WizardScope) {
      return lookup(elContext, (WizardScope) base, property.toString());
  }
  return null;
 }

Once, this is done, we can add the EL-resolver to the
faces-config.xml .

<faces-config...>
  <application>
    <el-resolver>de.laliluna.howto.application.WizardScopeResolver</el-resolver>

Now, we can use already our scope.

@ManagedBean
@CustomScoped("#{wizardScope}")
public class WizardBean {}

But you might wonder already, where did we create the id of the
wizard scope. Well, it is not yet created. We use the id null.
The next step is going to improve this. We create a managed bean
which allows to create and destroy scopes and let you deal with the
current scope.

@ManagedBean @ApplicationScoped
public class WizardHelper {
  public static final String WIZARD_SCOPE_KEY = "de.laliluna.WizardScope";
  private AtomicLong wizardId = new AtomicLong();
  public void start() {
    CustomFacesContext context = CustomFacesContext.getCurrent();
    context.setWizardId(String.valueOf(wizardId.incrementAndGet()));
  }
  public void end() {
    CustomFacesContext context = CustomFacesContext.getCurrent();
    WizardScopeResolver.destroyScope(context);
    context.setWizardId(null);
  }
  public <T> T get(String key) {
    return (T) getOrCreateScope().get(key);
  }
  public void put(String key, Object value) {
    getOrCreateScope().put(key, value);
  }
...

The start method is storing the wizardId in a custom FacesContext.
The FacesContext is created for every request and is actually an
inviting place to store things related to the current request. As a
consequence, we need a custom FacesContext class and a custom factory
as contexts are created by a factory. The normal approach is to
create a custom faces context factory is to extend from a wrapper
class. JSF provides a number of wrapper classes for internal
elements. Our custom context has an additional property wizardId.

public class CustomFacesContext extends FacesContextWrapper{
  private String wizardId;
  
  private FacesContext wrapped;
  
  public CustomFacesContext(FacesContext wrapped) {
    this.wrapped = wrapped;
    contextThreadLocal.set(this);
  }
  public static CustomFacesContext getCurrentInstance(){
    return contextThreadLocal.get();
  }
  @Override
  public void release() {
    this.wizardId = null;
    contextThreadLocal.set(null);
    contextThreadLocal.remove();
    super.release();
  }
  public boolean isWizardEnabled(){
    return wizardId != null;
  }
  public String getWizardId() {
    return wizardId;
  }
  public void setWizardId(String wizardId) {
    this.wizardId = wizardId;
  }
...
}

I am not showing the factory class here but only how to integrate it
into JSF. In the faces-config.xml you need to configure your
class in the factory section.

<faces-config...>
<application>
...
<factory>
  <faces-context-factory>
    de.laliluna.howto.application.CustomFacesContextFactory
  </faces-context-factory>
</factory>

There is a annoying pit fall, if you create a custom FacesContext.

It looks pretty straight forward to create a custom faces context.
The problems became rapidly visible, when using it. The provided
faces context of JSF has a static method getCurrentInstance ,
which returns the current instance extracted from a ThreadLocal .
This method is used internally at a number of places. It doesn’t
return your custom context but the wrapped default context. When
creating more custom things like components, event listener or other
custom factories, then sometimes the default (not your) context is
passed as method parameter. You need to be aware of this at all
places. As a consequence, your own custom context needs to provide
its own (redundant) ThreadLocal and a static method to return the
current instance. In my opinion this is a design weakness of JSF.
The next step is to create a component,
which can be integrated in a form and passed the wizard id with the
POST request. The component can be used as follows.

<h:form>
  <l:wizardId/>
  Age: <h:inputText value="#{wizardBean.age}"/>
  <h:commandButton action="#{wizardBean.finish}" value="Finish"/>
</h:form>

The implementation provides encode methods to render a hidden input
field and decode methods to extract the wizard id and store it in the
custom context.

public class WizardId extends UIInput {
  @Override
  public void encodeBegin(FacesContext context) throws IOException {
    ResponseWriter writer = context.getResponseWriter();
    assert (writer != null);
    writer.startElement("input", this);
    writer.writeAttribute("type", "hidden", "type");
    String clientId = getClientId(context);
    writer.writeAttribute("name", clientId, "clientId");
    // render default text specified
    CustomFacesContext customContext = (CustomFacesContext) context;
    if (customContext.isWizardEnabled()) {
      writer.writeAttribute("value", customContext.getWizardId(), null);
    }
    writer.endElement("input");
  }
  @Override
  public void encodeEnd(FacesContext context) throws IOException {
  }
  @Override
  public void decode(FacesContext context) {
// let the default implementation extract the value and store it in the submitted 
//value field
    super.decode(context);
    CustomFacesContext customContext = (CustomFacesContext) context;
    Object value = getSubmittedValue();
    if (value != null) {
      customContext.setWizardId(value.toString());
    }
  }
}

The final step is to keep track of a special case. An action method
can redirect to another page. Somehow we need to keep track of the
wizard id. We have two options:

Add the wizard id as URL parameter
/faces/mypage.xhtml?wizardId=4711
Store the wizard id temporarily in
the session scope and restore it immediately with the GET request

The first approach is used for example
by JBoss Seam but has the downside that your URL is polluted with the
id and the id is likely to be stored as well, if someone bookmarks
the page.
The second approach could have
theoretically a flaw, if the same user is sending to browser requests
quickly and by hazard the the second request is processed before the
redirect of the first. The second request would steal the wizard id.
I suppose that such a unwanted case is very hard to reproduce. As a
consequence, I think that the approach is a viable solution.
The resolution of a view and the actual
redirect is happening in the navigation handler. In order to store
the id, we need to provide a custom navigation handler. The JSF
default navigation handler is not very extension friendly. Important
steps are performed in private method. As a consequence, I needed to
copy the complete source code of the existing implementation and add
the lines to store the wizard id. Here is a snipped from the class
CustomNavigationHandler.

...
if (caseStruct.navCase.isRedirect()) {
  CustomFacesContext customFacesContext = CustomFacesContext.getCurrentInstance();
  if(customFacesContext.isWizardEnabled()){
  extContext.getSessionMap().put(Globals.WIZARD_SESSION_KEY, 
    customFacesContext.getWizardId());
}

The last step is to restore the wizard id after a REDIRECT. This can
be achieved in a phase listener.
I added the code in the class
GlobalPhaseListener. Right before the first phase, the restore
view phase, the id is written into the custom faces context.

public void beforePhase(PhaseEvent event) {
  // restore a wizard id
  if (event.getFacesContext() instanceof CustomFacesContext) {
    CustomFacesContext context = (CustomFacesContext) event.getFacesContext();
  String key = (String) context.getExternalContext()
      .getSessionMap().remove(Globals.WIZARD_SESSION_KEY);
  if (key != null) {
    context.setWizardId(key);
  }
}

That’s all we need to provide a wizard scope in our application. I
wouldn’t say that it is very simple but it is possible.

This implementation is not bullet prove. It only demonstrates, how
you can achieve a wizard scope. It doesn’t validate if a wizard page
is revisited using browser back for example or if you visit a wizard
page without a wizard being started.

Double submit handling

Double submits of input forms are not validated by default. To
validate double submit you can follow the approach used in the
Tapestry or the Stripes review. This approach adds a hidden field
with a unique token to the input form. The token is stored in a
application scoped variable or alternatively in the users session.

The latter approach is probably better as the session’s timeout would
clean up the users token as well. If the form is submitted, a phase
listener checks if there is a token in the form and if the token is
valid. It is valid, if it is included in the list of existing tokens.
For JSF you can implement this with either a custom component,
which is added to every form with double submit validation or
alternatively by overridden the renderer of the form.

You can find an example based on JSF 1.x on the following page.
You just need to port the concept to JSF 2:

<http://www.jroller.com/mert/entry/jsf_preventing_double_form_submit>

Custom components

A component is an element of a page. It is specified using a tag.
Below you can see a component rendering a link.

You can create your own components, which can be visual or non
visual. An example for a non visual component is a loop component
which let only render the components inside of the loop render
themselves.

There are two types of components in JSF 2. The classic components
which were available in JSF 1.x as well and so called composite
components which are a new feature of JSF 2. The classic components,
I will call them just components, are normal components which have
Java code to render or to process input etc. Just like the standard
JSF components. The composite components look like a code snippet
which can render a number of components using a single tag.
Let’s explore the composite components first and then we will have
a look at building real component starting from a hello world up to a
full flavoured Ajax component.

Composite components

A composite component is a snippet which renders a number of
components by just using a single tag. Instead of writing the
following code

<div>
<h:outputLabel value="Word (is required)"/>
  <h:inputText id="input" value="components.word" required="true">
    <f:ajax execute="input" event="blur" render="input-error"/>
  </h:inputText>
  <h:messages id="input-error" for="input"/>
</div>

you can use a single tag.

Composite components follows a convention over configuration approach
to integrate with JSF.
The following page makes use of composite components. The
namespace xmlns:my=“”http://java.sun.com/jsf/composite/sample">http://java.sun.com/jsf/composite/sample
defines the prefix and the location of the composite components.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"      
      xmlns:my="http://java.sun.com/jsf/composite/sample">
<head>
  <title>This will not be present in rendered output</title>
</head>
<body>
<h:form>
      <my:text label="Word (is required)" value="#{components.word}" required="true" />
      <my:text label="Age (between 5 and 99)" value="#{components.age}" required="true" >
        <f:validateDoubleRange for="input" minimum="5" maximum="99"/>
      </my:text>
      <h:commandButton value="Submit"/>
    </h:form>
</body>
</html>

A namespace like http://java.sun.com/jsf/composite/sample
assumes that the component is defined in a folder
web/resources/sample. The component <my:text> is defined
in the file text.html in that folder. Below you can see the
component definition. It is a normal xhtml file.
The tag <composite:interface> defines how the tag is used in a page. Our component has three
attributes: label, value and required. The first two attributes are
required, the last one is optional. In addition the tag
<composite:editableValueHolder> specifies that an input
component is included in the composite component.
The implementation is defined inside of
the tag <composite:implementation>. It uses the EL
expression to reference the attributes of the components.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"      
      xmlns:composite="http://java.sun.com/jsf/composite">
<head>
  <title>This will not be present in rendered output</title>
</head>
<body>
<composite:interface>
  <composite:attribute name="label" required="true"/>
  <composite:attribute name="value" required="true"/>
  <composite:attribute name="required" required="false"/>
  <composite:editableValueHolder name="input"/>
</composite:interface>
<composite:implementation>
  <h:outputLabel value="#{cc.attrs.label}"/>
  <h:inputText id="input" value="#{cc.attrs.value}" required="#{cc.attrs.required}">
    <f:ajax execute="input" event="blur" render="input-error"/>
  </h:inputText>
  <h:messages id="input-error" for="input"/>
</composite:implementation>
</body>
</html>

I think that composite components are a simple way to create code
snippets, you are going to use throughout your application.

A simple classic component

We are going to create a component which outputs *<div>hello</div>

in a facelet xhtml. Facelets are the default rendering approach
for JSF 2.
We need

a component class, which generates the output in our case
a tag library file which describes our component and its
attributes
an entry in the web.xml (Depending on the packaging)
to encourage JSF to find the tag library.

We don’t need at the moment a tag library definition file, any
entries in faces-config.xml or a renderer class.
You have two options to create a JSF component. The first one is
to extend from the class UIComponentBase and to override the
methods you need to change. This class provides a range of useful
methods you need in most cases and is intended to be used as base
class for new components. In JSF 2 this is the class to be used as
base class for components. If your component is very similar to an
existing component, then you may better use the existing as base
class. For example UIInput provides already a number of
methods for input handling, converting and validation. If your
component can receive input then you might use that class. All
components of JSF 2 extend the UIComponentBase. In our case,
we will use the UIComponentBase as we just want to output a
simple div .

Have a look at the class first, then I will give you a
description.

package de.laliluna.howto.components;
import javax.faces.component.UIComponentBase;
import javax.faces.component.FacesComponent;
import javax.faces.context.FacesContext;
import javax.faces.context.ResponseWriter;
import java.io.IOException;
@FacesComponent("de.laliluna.howto.components.MySampleComponent")
public class MySampleComponent extends UIComponentBase{
  public String getFamily() {
    return "de.laliluna.sample";
  }
  @Override
  public void encodeBegin(FacesContext context) throws IOException {
    ResponseWriter writer = context.getResponseWriter();
    writer.startElement("div", null);
    writer.write("hello");
    writer.endElement("div");
  }
}

@FacesComponent

The annotation defines that the class
de.laliluna.howto.components.MySampleComponent is a component
and that it is mapped to the type
“de.laliluna.howto.components.MySampleComponent”. I
used the same name but you may use a different name for your type.
JSF will scan the classpath of your application to find components.
In addition it will scan any JARs, if the JAR contains at least an
empty /META-INF/faces-config.xml.

Alternatively to the annotation
introduced in JSF 2, you can use an XML configuration. If you want to
use XML instead of annotations, add the following entry in your
faces-config.xml :

 <component>
     <component-type>de.laliluna.howto.components.MySampleComponent</component-type>
     <component-class>de.laliluna.howto.components.MySampleComponent</component-class>
   </component>
</faces-config>

Disabling the class path scan

If you don’t want to let JSF scan the class path, you can add the
attribute metadata-complete to the /WEB-INF/faces-config.xml .

<faces-config ...  metadata-complete="true">

getFamily

The method getFamily is used to select a renderer. JSF allows to
separate the component from the rendering in order to allow rendering
in different formats. ‘It allows’ means that you don’t have to.
In our case we overrode the encode method and did the rendering right
there. As a consequence this method plays no role at all.

Encoding and rendering

The rendering in JSF happens in the RenderPhase. If you have a
look into the source code of the UIComponentBase class, you
can see that the encodeBegin method creates an event,
checks if the component should actually render itself, than tries to
get a renderer and executes the method encodeBegin of the
renderer.

Using a separate renderer has the advantage that you can easily
replace either the component or the renderer by configuration in the
faces-config.xml. This is probably the best choice, if you write a
component collection to be used by other people or if you want to
provide rendering for different output formats. If you just want to
write a couple of components to generate XHTML code, just leave the
renderer aside.

I will provide you with some more insight into rendering later in
this chapter.

Taglib

The next step is to create a tag library. It describes the tags
and which component type will process it. Create the tag library
either in /WEB-INF or in /META-INF/ of the web root. The tag
reference the type name of the component not the class name. The name
of the taglib should end with .taglib.xml (see below). If you package
your components separately in a JAR, then the taglib is automatically
detected, if it is in the META-INF directory. Keep in mind that you
need at least an empty faces-config.xml in this directory as
well. Otherwise JSF doesn’t recognize the JAR as JSF module.

<!DOCTYPE facelet-taglib PUBLIC
  "-//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN"
  "http://java.sun.com/dtd/facelet-taglib_1_0.dtd">
<facelet-taglib>
  <namespace>http://www.laliluna.de/components/sample</namespace>
  <tag>
    <tag-name>hello</tag-name>
    <component>
      <component-type>de.laliluna.howto.components.MySampleComponent</component-type>
    </component>
  </tag>
</facelet-taglib>

The last step is to add the taglib as param in the web.xml. The
param-value contains a semicolon separated list of taglibs.

<context-param>
  <param-name>javax.faces.FACELETS_LIBRARIES</param-name>
  <param-value>/WEB-INF/sample-components.taglib.xml</param-value>
</context-param>

Please note that we only need to add
this parameter if we create our components directly in our web
application. If you package components separately in JARs and add
them to WEB-INF/lib of your web application, then you only need to
define an at least empty faces-config.xml and the taglib in
/META-INF of your component JAR. VERY IMPORTANT: In that case the
taglib file must end with .taglib.xml (DOT taglib DOT xml).
Here is a sample directory structure
with components packaged as JAR.

home.xhtml 
index.jsp 
template.xhtml 
WEB-INF/classes/de/laliluna/howto/beans/ArticleBean.class 
WEB-INF/classes/de/laliluna/howto/model/Article.class 
WEB-INF/classes/de/laliluna/howto/services/ArticleService.class 
WEB-INF/classes/de/laliluna/howto/services/ArticleServiceImpl.class 
WEB-INF/classes/de/laliluna/howto/services/ServiceFactory.class 
WEB-INF/classes/de/laliluna/howto/services/ServiceFactoryImp.class 
WEB-INF/faces-config.xml 
WEB-INF/lib/components.jar 
WEB-INF/web.xml

The content of the components archive is

META-INF/MANIFEST.MF
META-INF/faces-config.xml
META-INF/sample-components.tld
META-INF/sample-components.taglib.xml
de/laliluna/howto/components/MySampleComponent.class

Rendering

A page or to use the JSF terminology a view consists of a
component tree. There is a root component with a number of child
components which may have child components, which may have child
components which may …. During the rendering the component tree is
traversed and every component is ask to render it self (more or
less).

The rendering happens in the render response phase. The phase
calls the renderView method of the view handler. The view
handler determines the view handling strategy of the view declaration
language (Facelets or JSP) and, in case of a Facelet, executes the
renderView method of the FaceletViewHandlingStrategy. This
method calls the encodeAll method of the root component of the
view to start the rendering. The following picture shows a slightly
shorted encodeAll method of the UIComponent class and explains
every step.

The UIComponentBase provides default implementations for all
methods called in encodeAll.

Other sources

Nice series of article on various new features of JSF 2
http://www.ibm.com/developerworks/java/library/j-jsf2fu1/index.html

Short article on writing a first composite component
http://weblogs.java.net/blog/driscoll/archive/2008/11/writing_a_simpl.html

Articles on component development based on JSF 1.2
http://www.ibm.com/developerworks/web/library/wa-aj-simplejava4.html
http://www.jsftutorials.net/components/step1.html

Article on composite components with JSF 2
http://weblogs.java.net/blog/driscoll/archive/2008/11/writing_a_simpl.html

Article on Ajax enabled component development with JSF 2
http://weblogs.java.net/blog/driscoll/archive/2009/10/09/jsf-2-custom-java-components-and-ajax-behaviors

Article showing how to implement a custom lifecycle to handle
exceptions. Though this can be better solved with an exception
handler in JSF 2, the article is still useful as it explains how to
create your own lifecycle factory.
http://insights2jsf.wordpress.com/2009/07/20/using-a-custom-lifecycle-implementation-to-handle-exceptions-in-jsf-1-2/

Detailed online book on JSF 2 with MyFaces, German language only
http://jsfatwork.irian.at/semistatic/introduction.html

Article on custom EL-resolver
http://java.sun.com/mailers/techtips/enterprise/2006/TechTips_Aug06.html

Blog Entry on exception handling with JSF 2
http://weblogs.java.net/blog/edburns/archive/2009/09/03/dealing-gracefully-viewexpiredexception-jsf2

Blog article on Redirect-on-Post with JSF 1.2
http://balusc.blogspot.com/2007/03/post-redirect-get-pattern.html

Double submit handling for input forms
Was written for JSF 1.x but you can follow the same idea to
implement it for JSF 2 as well.
http://www.jroller.com/mert/entry/jsf_preventing_double_form_submit

Component libraries

Matrix comparing different JSF 1.2 component collections
http://www.jsfmatrix.net/

New component collection dedicated to JSF 2
http://kenai.com/projects/scales/pages/Home

IceFaces
http://www.icefaces.org/

JBoss Richfaces
http://www.jboss.org/richfaces

MyFaces Trinidad and Tobago
http://myfaces.apache.org/

Oracle ADF
http://www.oracle.com/technology/products/adf/index.html

PrimeFaces
http://primefaces.prime.com.tr/en/

Security related sources

Article on security with JSF
http://blogs.sun.com/enterprisetechtips/entry/improving_jsf_security_configuration_with

Article on programmatically logging in using JAAS
http://weblogs.java.net/blog/2006/03/07/repost-using-jaas-jsf

Article explaining how to write your own JAAS module
http://www.javaranch.com/journal/2008/04/authentication-using-JAAS.html

Performance and scalability

This chapter will only be included in the PDF version, which is
available at http://www.laliluna.de/shop

Devoxx presentation on Choosing Web Frameworks

2009-09-17T00:00:00Z

Devoxx presentation on Choosing Web Frameworks

Devoxx has just confirmed that I can hold a presentation on selecting web frameworks. This is the first time, that I am invited and I am really happy about the invitation. I am looking forward to see you on the Devoxx conference.

http://www.devoxx.com/display/DV09/BOF+Day+2

Best Regards / Viele Grüße

Sebastian Hennebrueder