New Features of JSF 2.0 - Part 1

So, time to move to ICEFaces 2.0, isn´t it ? But if you are talking about ICEFaces 2.0, you have to know what JSF 2.0 is doing for you. So here is the first part of my "Fancy things you can expect from JSF 2.0" Series.

One thing first: JSPs are deprecated, so if you plan to migrate your applications, keep that in mind. And keep it in mind when you are reading this series of blog entries, because (for example) Ressource Management won´t work in JSPs.

JSF Resource Management

JSF 2.0 offers something that is called "Resource Management". What does that mean ? It means, that you can declaratively define the ressource you want to access, JSF picks the newest one for you out of your folder and you don´t have to care about folders, slashes or anything else.
What is a Resource ? A Resource may be a javascript file, a css file or a graphic file.

If you wanted to display an image in JSF 1.2 you had to write something like this:

 <h:graphicImage value="/img/myPictures/picture.png" /> 

The same tag would look like this in JSF 2.0:

  <h:graphicImage value="#{resource['myPictures:picture.png']}" /> 

Or simpler :

  <h:graphicImage name="picture.png" library="myPictures" /> 

Looks confusing ? Wait a sec, this is how it works:

Convention over Configuration

All your images are located in the standard resource folder called "resources". Within this folder are the library folders and within them folders for the resources to be displayed. This is the convention you have to follow from now on. This will help you to keep your files in place. It also helps you to address your resources, because all you have to care about is your library folder and your image name.

#{resource[... always specifies access to a ressource in JSF 2.0. To access a library with a specific resource use the following pattern: ['libraryName:resourceName'].


The JSF 2.0 Resource Management allows versioning of files. How does that work? Well, all your files can be updated at runtime, without the need for a deployment and without to overwrite the file. Just add a new version and the next request for a resource will carry out your updated one.

Part 1 - New Library Version

if you want to add a new library version to your web application just add a versionized folder by creating a folder with the name "1_1". Putyour updated file into this folder.
Your folder should now look like this:


The upper picture is the unmodified version, that´s still present in your application, Version 1_1 goes into its own folder. Ever other 1_1 versionized picture for the myPictures library would also go into this folder.

Part 2 - New Image Version

If you want to update your image without having to create a new library version, just do the following: Add a new folder, named "picture.png" and place all future versions of your file into this folder like this:


This example shows how Version 1_2 of the library version 1_1 would be the most actual to be delivered to the browser. All other files would reside untouched on the server.

Part 3 - Updating JARs

A very nice thing is, that this is also affecting resources in JARs, so you may update a javascript library without changing the original source.


  • You don´t have to care about how to deploy new versions of your files
  • You don´t have to care about how to access your resources, or a Junoir Programmer always forgetting the "/" at the beginning

If you liked this tutorial it would be very nice, if you could click on some of the google ads you see on the right side. It helps me run this block and motivates me ;)

If you have any questions, feel free to leave a comment.