Saturday, May 28, 2011

ICEFaces redux

Ok, I've just started to take a look back at JSF (ICEFaces 1.8, to be precise): this means also using JSF 1.1/1.2 instead of the more recent JSF 2.0 (which is supported in ICEFaces 2.0). Why? Just corporate legacy mindset ;)

I used ICEFaces 1.7 with JBoss SEAM 2.1 and I still feel the pain: why not using RichFaces instead of ICEFaces? Corporate decision-making is out of my sight :| Ok, since now it is a must for me to understand it right, I've decided to take an easy-going approach: just beginning with the site tutorials and then take small steps with my own modifications.

Ok, let's get started. Downloaded ICEFaces 1.8.2 from the site and deployed my tutorial WAR (timezone #1) into my local tomcat 6.0.32. Bam!


"ICEFaces is back" has been my first thought but kept on trying with the other tutorials which, fortunately, did work so I could continue.

The first thing I noticed with just clean JSF 1.2 is the lack of any dependency injection and/or interceptor feature: just a plain faces-contex.xml file where to put your page beans.

Having appreciated the benefits of the Spring Framework, I just switched my focus to make Spring publish the application context's beans as JSF managed beans. The documentation provided the tips, so ... did I just put the spring jars within the tutorial example and run it? Of course not! Since I've also appreciated maven, I also mavenized the project: this has proved to be really easy (just searching the dependencies over google in order to add them to my pom.xml file).

To cut it short, I've modified the web.xml in order to introduce Spring specifics configurations inside it (just like any other Spring web application out there):



Then I modified the faces-config.xml according to the Spring documentation in order to introduces Spring JSF Expression Language (EL) resolver:



Noted the lack of any managed bean definition, eh?

Finally I created a simple application-context.xml file which defines the bean used in the example (which, being created by Spring bean factory, means that it will benefit of dependency injection and AOP like security, transactions and so on):



Ok, next step is to make it cooler by using annotations and see how Spring controllers can fit within it. Ah, and also taking a look at how AJAX works with JSF/ICEFaces/Spring.