Looking for a JSF Tutorial or an easy to go  JSF example? Read on…

What you need ?

Tomcat server . You can download from here: http://tomcat.apache.org/download-55.cgi

And  20 minutes of your time…

What we will achieve ?

Your first JSF program. Nothing fancy. No bells and whistles- just a plain vanilla JSF program which will say hello to you.

Note: If you are looking for a JSF example to show you Backing Beans or JSF Navigation- then this is probably not for you. This is just to give you started real quick on JSF. Other good things about JSF will follow later.


That you are running your tomcat server on port 8080.

This example was tested on windows XP platform- but should really work anywhere.

Getting started

Step1 :D ownload the tutoral from here.

Step 2: Unzip the file under your webapps folder under Tomcat installation

Step 3: Copy this URL to your favourite browser


Voila !!!

Tutorial explained

1) web.xml.

This specified the path for teh Faces-config file. the heart of a JSF application


This is to load the Faces Servlet before anything else.

<servlet-name>Faces Servlet</servlet-name>
<load-on-startup> 1 </load-on-startup>

This will map any URL ending with *.rn to be routed to the Faces Servlet

<servlet-name>Faces Servlet</servlet-name>

2) Faces-config.xml: Deliberately kept empty. Just a place holder for you to do greater things later on.

3) hellojsf.jsp : A very simple JSP.

4) hellojsf.txt: This is a simple text file. which can be loaded just like any other web resource.


I have included this as a troubleshooting aid- if you are unable to load the JSP try loading this instead. This bypasses the whole faces servlet so has a better chance of being loaded

What’s Next ?

This JSF tutorial was just to get your feet wet .Next logical step would be to get introduced to JSF Navigation and Backing Beans. I will be posting a tutorial on that soon.

If this example doesnt work for some reason – please leave a note and I will try to assist. Also  see my other posts on troubleshooting  http://www.rajivnarula.com/blog/tags/troubleshooting/


Visit to the bank

You walk in to the bank- to deposit cash.

You stand in the line- meet the Teller who does the transaction with you.

Do you really  care whether its Joe or Mary behind the counter?

No. You do not.

Because your contract with the Bank is via the teller (:read interface) not Joe who happens to be there – that day or maybe everyday (:read implementation)

It’s all about the contract

Interface is nothing but a formal contract . All classes which implement that interface- are basically declaring that we will honor this contract and will provide you the service as said by this interface.

The beauty of this paradigm is that – this keeps your two classes blissfully unaware of each other – allowing you to change one without drastically affecting another or at least controlling the affect on another.


Java API is actually full of very good examples of this.

e.g. JDBC Driver . All JDBC applications use the Driver interface – to get a connection etc.

Because we program against this Driver- we do not care what that implementation is.

The implementation could be an Oracle Driver or a MySQL Driver.

Your application would work the same- for both the databases- as long as you have programmed to the interface- without depending upon the actual implementation.

Another example: Java Collection API List,Set,Map Interfaces.

If your classes take as input one of these interfaces- the caller may send you a different class- ArrayList or LinkedList- and you wont notice a thing. That’s why its strongly encouraged that your input parameters or return types should be an interface rather than a class.

And Spring

The best thing I like about Spring is- it strongly encourages you to program to interfaces by using Config files- which bind implementing classes to each other using interfaces

You code uses only interfaces you refer to implementation only in the config file

How do I know if I did program to interfaces or not ?

Look at the input parameters and return type of your public API.

If you return a class rather than an interface- you are exposing your implementation detail.The caller is not programing to your interface -but to your classes.

If the input parameters of your public API is a class- you are dependent upon the internal implementation of the caller- and not on it’s interfaces.


Following is a collection of some principles\suggestions\rules\guidelines- whatever you wish to call them- to be kept in mind while designing software.

Some of this was inspired by Head-First Design patterns book- which I concluded recently. An excellent read- BTW.

I would recommend every earnest programmer to keep these principles posted at a visible location in his/her work place.

A) The Single Responsibility Principle – A class should have only one reason to change.
B) Open Closed Principle – Classes should be open for design but closed for modification .
C) Liskov substitution principle
D) Interface Segregation Principle – The dependency of one class to another one should depend on the smallest possible interface.
E) Dependency Inversion Principle – High level modules should not depend upon low level modules. Both should depend upon abstractions.
F) Encapsulate what varies
G) Favor composition over inheritance
H) Program to interface ,not implementations
I) Strive for loosely coupled designs between objects that interact
J) Depend upon abstraction, do not depend upon concrete classes
K) Principle of least knowledge – Only talk to your friends
L) Inversion of control- Don’t call us, we’ll call you.
M) Tell, Don’t Ask

© 2011 Technology Cafe Suffusion theme by Sayontan Sinha