What is OmniFaces?
Tired of reinventing
FacesUtils utility classes for every JSF web application and/or homebrewing custom components, taghandlers, etc to workaround or enhance some general shortcomings in JSF? OmniFaces may be what you're looking for!
OmniFaces is a utility library for JSF 2 that focusses on utilities that ease everyday tasks with the standard JSF API. OmniFaces is a response to frequently recurring problems encountered during ages of professional JSF development of the JDevelopment team and from questions being asked on Stack Overflow.
Contrary to some of the other excellent JSF 2 component libraries out there (like PrimeFaces, BootsFaces, or ButterFaces), OmniFaces does not contain any of the beautiful visually oriented components that those other libraries are already known and loved for. As such, OmniFaces does not and will never contain things like rich table components or tasty look'n'feels. OmniFaces is more geared toward "utilities" that solve everyday practical problems and workarounds for (small) shortcomings in the JSF API. Such utilities and workarounds can be based on components, but OmniFaces does not necessarily strive to be a "component library" perse. OmniFaces can just be used together with any component library.
Besides utility classes for working with the JSF API from Java code, such as Faces and Messages, and utility and enhanced components, such as <o:highlight> and <o:viewParam>, OmniFaces will include various general converters, validators and Facelets tag handlers. These will range from "all-or-none" validators to automatic <f:selectItem(s)> converters. There are also specialized handlers, such as a full ajax exception handler and a combined resource handler. CDI specific features are available such as transparent support for injection in @FacesConverter and @FacesValidator, an improved @ViewScoped which immediately destroys on unload, and web socket based push via <o:socket>. For a full overview of what's all available in OmniFaces and several live examples, look at the showcase.
An important design goal will be to have as few dependencies as possible and to be minimally invasive. So far, OmniFaces 2.x requires Java 1.7, JSF 2.2, EL 2.2, Servlet 3.0, CDI 1.1 and WebSocket 1.0 APIs which is already minimally available in a fairly modern servlet container serving a JSF 2.2 web application. Legacy OmniFaces 1.x only requires Java 1.6, JSF 2.0, EL 2.1 and Servlet 2.5 APIs which is already minimally available in a fairly modern servlet container serving a JSF 2.x web application.
Since OmniFaces 1.6 there was an optional dependency on CDI, which turned out to be troublesome in some outdated environments, so they were since version 1.10 removed from version 1.x for a better compatibility with those environments. The CDI specific features remain in version 2.x whereby the CDI dependency is thus made required. Version 1.x users who are already using CDI specific features on a JSF 2.1 environment should be able to effortlessly migrate to version 2.x. OmniFaces 2.0/2.1 is unofficially backwards compatible with JSF 2.1. OmniFaces 2.2 is not anymore backwards compatible with JSF 2.1.
Since OmniFaces 2.3 there is a required dependency on JSR356 WebSocket which is already available in any Java EE 7 container and in even earlier versions of servletcontainers (Tomcat supports it since 7.0.27 and Jetty supports it since 9.1.0).
All OmniFaces versions have an optional dependency on JSR303 Bean Validation which is only required when you start to actually use
OmniFaces should principally integrate perfectly well with most other JSF component libraries. Even more, the OmniFaces showcase application uses PrimeFaces. If you encounter problems in combination with a specific component library, then by all means report an issue. We'll investigate if it's caused by OmniFaces or the component library in question and fix it or propose a workaround solution, depending on the nature of the problem. Note that OmniFaces is due to the mandatory Servlet API dependency not compatible with portlets.
It is a matter of dropping the OmniFaces 2.4 JAR file in
Maven users can add OmniFaces by adding the following Maven coordinates to
pom.xml of the WAR project:
<dependency> <groupId>org.omnifaces</groupId> <artifactId>omnifaces</artifactId> <version>2.4</version> </dependency>
For users on outdated environments who can't/won't use CDI, use 1.14 instead. It doesn't contain anything from CDI nor new things which were added in 2.x, but it does contain enhancements and bugfixes to existing 1.x things.
The OmniFaces UI components/taghandlers and EL functions are available under the following XML namespaces:
OmniFaces is designed as a WAR library (web fragment library) and therefore can't be placed elsewhere in the webapp's runtime classpath outside WAR's own
/WEB-INF/lib, such as EAR's
/lib or even server's or JRE's own
/lib. When OmniFaces JAR file is misplaced this way, then the webapp will be unable to find OmniFaces-bundled JSF/CDI annotated classes and throw exceptions related to this during deploy or runtime. To solve it, put back OmniFaces in WAR's
/WEB-INF/lib. Also note that you shouldn't have duplicate OmniFaces JAR files, otherwise CDI will throw exceptions related to ambiguous dependencies during deploy.
Version history can be found in "What's new" page at the showcase.
OmniFaces 2.0 - 2.4
Required: Java 1.7, JSF 2.2, EL 2.2, Servlet 3.0, CDI 1.1 and since 2.3 WS 1.0
Optional: BV 1.0
- 2.4 (1 Jul 2016) - library - sources - javadoc
- 2.3 (1 Apr 2016) - library - sources - javadoc
- 2.2 (24 Nov 2015) - library - sources - javadoc
- 2.1 (3 Jun 2015) - library - sources - javadoc
- 2.0 (24 Nov 2014) - library - sources - javadoc
OmniFaces 1.10 - 1.14
Required: Java 1.6, JSF 2.0, EL 2.1, Servlet 2.5
Optional: BV 1.0
- 1.14 (1 Jul 2016) - library - sources - javadoc
- 1.13 (1 Apr 2016) - library - sources - javadoc
- 1.12.1 (26 Nov 2015) - library - sources - javadoc
- 1.11 (3 Jun 2015) - library - sources - javadoc
- 1.10 (24 Nov 2014) - library - sources - javadoc
OmniFaces 1.0 - 1.8
Required: Java 1.6, JSF 2.0, EL 2.1, Servlet 2.5
Optional: BV 1.0 and since 1.6 CDI 1.0
- 1.8.3 (3 Jun 2014) - library - sources - javadoc
- 1.7 (12 Jan 2014) - library - sources - javadoc
- 1.6.3 (18 Oct 2013) - library - sources - javadoc
- 1.5 (10 Jun 2013) - library - sources - javadoc
- 1.4.1 (12 Mar 2013) - library - sources - javadoc
- 1.3 (20 Dec 2012) - library - sources - javadoc
- 1.2 (20 Oct 2012) - library - sources - javadoc
- 1.1 (10 Jul 2012) - library - sources - javadoc
- 1.0 (1 Jun 2012) - library - sources
If you like to play around with the newest of the newest, hereby accepting the risk that new classes/methods may be moved/renamed without notice, then grab the 2.5-SNAPSHOT instead.
Maven users can add OmniFaces SNAPSHOT by adding the following Maven coordinates to pom.xml:
<repositories> <repository> <id>oss.sonatype.org-snapshot</id> <url>http://oss.sonatype.org/content/repositories/snapshots</url> <releases><enabled>false</enabled></releases> <snapshots><enabled>true</enabled></snapshots> </repository> </repositories> <dependencies> <dependency> <groupId>org.omnifaces</groupId> <artifactId>omnifaces</artifactId> <version>2.5-SNAPSHOT</version> </dependency> </dependencies>
For starters, a "snapshot" is just the current/latest build. It's far from a release. We may make code changes and create snapshots so now and then before final version release. Those changes will then get reflected in your project if you use the snapshot version in your Maven project and forces an update. It will generally work just fine, but imagine if we make some mistake and notice it only a few days or weeks later, or are trying to test something which may not necessarily work in all environments, then your project may be affected. That's why it's advisable to not use snapshots of 3rd party libraries in production, unless you have your own build system which can "lock" a specific snapshot version, or closely track (and understand) any changes in the codebase. See also a.o. What exactly is a Maven snapshot?.
- OmniFaces API documentation
- OmniFaces VDL documentation
- OmniFaces wiki pages
Mastering OmniFaces is since October 5, 2015 available at Amazon.com. This book was created in cooperation with the creators of OmniFaces, Bauke Scholtz and Arjan Tijms. From the beginning on, they worked together with Anghel Leonard and Constantin Alin to get this book ready, and have reviewed it from top to bottom.
A little over 500 pages, this book goes into depth identifying general JSF problems and describing how OmniFaces has solved it, hereby uncovering several patterns and tricks. Basically, the working of every OmniFaces component, taghandler, converter, validator, and several handlers and listeners is break down in the book in a problem-to-solution approach. Reading this book is a true learning exercise as to exploiting JSF API, creating custom components, renderers, tagfiles and what not provided by JSF API in order to solve common problems.
A must read if you also like Mastering JSF 2.2 from the same author!
PrimeFaces & OmniFaces powers combined
PrimeFaces & OmniFaces powers combined is an e-book of Anghel Leonard containing complete examples showing off situations when the PrimeFaces UIs take advantage of OmniFaces help.
If you have found bugs or have new ideas, feel free to open a new issue.
If you have general feedback that's not either a question, bug report or feature request, or if you have a review/rating, please feel free to leave it at OpenHUB.
OmniFaces in the worldwide news and literature
- Oracle - Java Magazine January/February 2016
- Oracle - Oracle Announces Winners of the 2015 Duke’s Choice Award
- Oracle - Duke’s Choice Awards 2015
- YouTube - Programação Web com Java - 177: Introdução ao OmniFaces - 193: SelectItemsConverter - 197: ResetInputAjaxActionListener (Portuguese)
- ZEEF - OmniFaces Utilities by Anghel Leonard
- Beyond Java - OmniFaces CombinedResourceHandler Gives Your Application a Boost
- JAXenter - JSF-Bibliothek OmniFaces 2.0 erschienen (German)
- OSChina - OmniFaces 2.0 发布，JSF2 工具库 (Chinese)
- OmniFaces Fans - OmniFaces 2.0 is here!
- Beyond Java - OmniFaces 2.0 released
- Thoughts on software development - Building dynamic responsive multi-level menus with plain HTML and OmniFaces
- Java vs .NET SQLWorld presentation (Japanese)
- Mastering JavaServer Faces 2.2 - a.o. Chapter 7
- Bytes Lounge - How to cache component rendering in JSF example
- Beyond Java - Why JSF 2.0 Hides Exceptions When Using AJAX (about FullAjaxExceptionHandlerFactory)
- Adictos al Trabajo - Omnifaces: una librería de utilidades para JSF2 (Spanish)
- JSFCentral - Arjan Tijms and Bauke Scholtz (BalusC) Talk about OmniFaces and Building zeef.com
- OIO - JSF Performance Tuning (with CombinedResourceHandler)
- Challenge Java EE - JSFでPDFファイルを開いたりダウンロードしたりしてみる (download PDF files in JSF) (Japanese)
- OSChina - OmniFaces 1.4 发布，JSF2 工具库 (Chinese)
- JAXenter - JSF-Bibliothek OmniFaces vereinfacht HTML Messages (German)
- JAXenter - Besser spät als nie: JSF-Bibliothek OmniFaces 1.4 mit überarbeiteten FacesViews (German)
- JAXenter - Nie wieder "View Expired": JSF-Bibliothek OmniFaces 1.3 erschienen (German)
- Entwicklertagebuch - OmniFaces - Das Schweizer Taschenmescher für JSF-Entwickler (German)
- Un Poco de Java - OmniFaces: librería de utilidad para JSF (Spanish)
- InfoQ - OmniFaces: uma biblioteca de utilitários para JSF (the Brazilian-Portuguese translation of previous English article)
- InfoQ - OmniFaces: A Utility Library for Java Server Faces