I've found some tutorials about integrating JSF technology with Spring Boot, but it seems a rather involved work to get OmniFaces working with Spring Boot. Is it a good idea to integrate these two together at all?
Asked
Active
Viewed 2,447 times
6
-
I've got the latest omnifaces 1.x version working with JSF 2.2 in a Spring Boot project. I believe the real integration relates to make JSF work in Spring Boot (which is couple of steps), not omnifaces. The reason why I keep with the 1.x branch is that it fulfills my requirements and doesn't require CDI. – Xtreme Biker Jan 01 '17 at 16:48
-
@XtremeBiker: I didn't know that omnifaces 1.x version does not require CDI. Thanks. – Dandelion Jan 01 '17 at 17:42
1 Answers
14
First of all, Java EE and Spring are competing frameworks. Generally it's the easiest to pick the one or the other instead of attempting to mix them. It will in long term end up in less confusion to beginners and less annoyances as to interoperability.
The Java EE framework is geared towards Java EE containers (WildFly, TomEE, Payara, etc), while the Spring framework is geared towards barebones servlet containers (Tomcat, Jetty, etc). JSF, whilst being part of Java EE framework, initially didn't require much of other Java EE artifacts as dependency so that it could effortlessly run in barebones servlet containers as well. Only JSTL was required as another part of Java EE, which is rather trivial to manually install in a barebones servlet container.
Since JSF version 2.0, an optional Bean Validation (JSR303) dependency was added, which is also easy to install in a barebones servlet container.
Since JSF version 2.2, an optional CDI dependency was added, which is in case of Weld also easy to install in a barebones servlet container. However, here comes the trouble: Spring only partially supports CDI. Anything from javax.inject.* is supported, but nothing from javax.enterprise.context.* is supported. This forces users less or more to use Spring-managed beans instead of CDI-managed beans.
As per the future JSF version 2.3, JSF own @ManagedBean facility will be deprecated, CDI dependency will be made required, and more optional Java EE dependencies will be added: WebSocket (JSR356) and JSONP (JSR353). CDI being fully required doesn't play well together with Spring as they refuse to fully implement CDI.
OmniFaces in turn, is fully geared to JSF. OmniFaces 1.x is targeted to JSF 2.0 and doesn't require CDI. OmniFaces 1.1x is even CDI-less. OmniFaces 2.x is targeted to JSF 2.2, with the difference that CDI is made required instead of optional. This is done so because OmniFaces is designed with "best practices" in mind and tries to force users to move to CDI for bean management, particularly because JSF will by itself also head in the direction of making CDI required and thus OmniFaces 2.x users will be better prepared for the future.
Given the CDI issues explained above, you should by now probably realize that you'd best pick CDI-less OmniFaces 1.1x in case you want to use Spring instead of Java EE. The latest 1.1x version is 1.14 and this happens to be integrated as part of JoinFaces.
What is JoinFaces?
This project enables JSF usage inside JAR packaged Spring Boot Application.
It autoconfigures PrimeFaces, PrimeFaces Extensions, BootsFaces, ButterFaces, RichFaces, OmniFaces, AngularFaces, Mojarra and MyFaces libraries to run at embedded Tomcat, Jetty or Undertow servlet containers.
Although I'm no Spring guy and can't tell from own experience, I'd say that JoinFaces is your best pick in case you'd like to go ahead with Spring Boot + JSF.
Note that whilst JoinFaces site says it supports CDI annotations, it does not mean that it supports the CDI implementation, it really only supports the annotations from javax.inject.* package.
