You're making a conceptual mistake. JSF is not a view technology. JSF is a MVC framework. Exactly like as Spring MVC, albeit they have both a different ideology; JSF is component based MVC and Spring MVC is request based MVC. Thus they are full competitors. You cannot mix them. You should choose the one or the other. Instead, JSP and Facelets are true view technologies. Since Java EE 6 (December 2009), JSP is deprecated and replaced by Facelets (XHTML) as default view technology for JSF.
You can use Spring MVC with JSP view technology. You can also use Spring MVC with Facelets view technology (and many others). But you can not use Spring MVC with JSF components let alone with JSF component libraries like PrimeFaces. JSF output components may work, but JSF input components won't work at all. Spring MVC has already its own <form:xxx> tags for input. Even if you mix them, you will end up with half of the functionality from both frameworks in a mingled and confusing code base. This is not making any sense. If all you want is to use the same UI as PrimeFaces, just grab jQuery UI. It's also exactly what PrimeFaces is using under the covers. PrimeFaces is a jQuery-based JSF component library.
From the other side on, it can also be very good that you confused Spring IoC/DI with Spring MVC. Spring IoC/DI is in turn usable together with JSF. You can replace the JSF managed bean facility (@ManagedBean and friends) by Spring managed bean facility (@Component and friends), usually with the sole purpose in order to use @Autowired in a JSF backing bean. But that's it. The JSF MVC framework lifecycle, the JSF components and the view technology remain unchanged. The standard Java EE equivalent of that would be using CDI (and EJB).
The same story applies to Spring Security. You can use it together with JSF, you should however not follow Spring Security + Spring MVC targeted documentation/examples in order to configure it, but only Spring Security + JSF ones. Do note that Spring Security constraints on business actions only works when you replace the JSF managed bean facility by Spring managed bean facility. So that would still require a "Integrate Spring in JSF" as described in previous paragraph. The standard Java EE equivalent of this all would be using container managed security (JAAS/JASPIC) via <security-constraint> entries in web.xml.
The same story also applies to Spring WebFlow. You only also need to make sure that you're using most recent version of Spring WebFlow as older versions cause conflicts when used together with multiple JSF component libraries. Moreover, since JSF 2.2, new Faces Flows feature was introduced as part of standard Java EE API, hereby basically making Spring WebFlow superfluous.
Then there is Spring Boot. This does not have a direct equivalent in Java EE. Spring Boot basically enables you to execute a Java EE application using a plain Java application class with a main() method "in an easy and abstract way". Without Spring Boot it's surely possible (otherwise Spring Boot would never have existed), it's only a bit more work as to configuration as you have to take into account server-specific details based on its documentation. For example: Undertow and Jetty.
Coming back to JSF and Spring MVC, if really necessary, you can safely run Spring MVC and JSF next to each other in same web application, but they won't interoperate in server side. They will run completely independently. They will at most touch each other in the client side, if some JavaScript in a JSF-generated HTML page happens to invoke a Spring based REST web service call in the same web application. But that Spring web service would then not need/have to know anything about JSF in order to respond accordingly. The standard Java EE equivalent of that Spring REST webservice is JAX-RS.
The upcoming Java EE 8 will come with a new request based MVC framework, named just "MVC", based on lessons of both JSF and Spring MVC, hereby supplanting Spring MVC and providing a standard alternative to JSF.
See also:
