The last time I looked at JSF was when it was 1.0 and after seeing that every request was a POST and the deplorable UI widgets I ran away screaming.
I don't blame you, in fact that's what everyone did. Even its own designer ran away in agony after seeing what monstrosity he had created!
Luckily around 2005 Ed Burns and his team took over and after quick-fixing some issues for JSF 1.2 in a short-time he got the free hand to largely redesign JSF for 2.0. He listened extremely well to the community and nearly everything the community ever complained about was addressed (in many cases in close cooperation with that community).
Ed Burns isn't shy at all to just accept a community solution instead of building something himself. For instance instead of developing a templating language themselves for JSF, the team just took the existing superior Facelets.
JSF 2.x is just like EJB2 vs EJB3; it's a massive overhaul and it's very hard to find any concrete flaws with it, while in JSF 1.x this was all too easy.
I'm curious to see a good non-emotional evaluation of when to use JSF and when not to. I work with Spring MVC and YUI 3 myself and am very impressed with the flexibility and power they provide. I have to admit that on the backoffice side of things I often find I have to do a lot more coding than I would like on boiler plate type CRUD operations. On the front end, I can't imagine that any standard widget would suit my needs as I need speed and customizability without the fatness you tend to find in a "one widget to rule them all".
Well, you can easily build your own components via the composite component feature. This is just a simple template in which you put markup and javascipt. You place this in the /resources folder and it's automatically available as a component.
GET is fully supported HTTP verb now, and the integration with EJB, JPA and bean validation is superb. This means that typical CRUD screens are very easy to make. A slim JSF backing bean calls out to an (EJB) service, which returns a JPA entity that is directly passed to the view. You bind properties of this entity to fields. Validation can happen automatically based on Bean Validation annotations or Type converters/validators, or more explicitly by re-usable converters/validators that you attach to these fields.
It's really simple and straightforward.
I also like the power Facelets templates give me. I lot of re-occuring things can be put into master templates and a specific page only fills in what makes that page specific.
Also, how easy is it to integrate JSF into existing MVC applications? Can it be JSF and MVC or does have to be JSF or MVC?
JSF *is* a MVC framework. More specifically, it's used to implement the view part. The controller is given (you don't write it), but a backing bean or (optionally) navigation rules augment it. In JSF-speak, the backing bean is already the model, but practically the (EJB) services that it calls out to are more considered to be the model.
An advantage of JSF seems to be that it's now really gaining momentum. The Java web framework space always has been extremely fragmented, and with the exception of Struts around 2000, no framework ever got a leading position. You may be in love with Spring MVC, but the next developer is totally into Wicket and hates Spring MVC, while yet another developer hates you both and advocates using GWT exclusively.
It seems that JSF is the one web framework in Java on its way to a relatively dominant position.