OmniFaces

Every Faces project grows the same helper classes. One fetches a request parameter without navigating FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap(); one adds a FacesMessage in one line; one turns a byte[] into an image; one registers a filter to compress the response. OmniFaces is that collection, maintained as a library: a utility library for standard Faces. Its own description is that it focuses on utilities that ease everyday tasks with the standard Faces API, and that it does not and will not contain visual components such as rich tables or look and feels. It works with any component library; the OmniFaces showcase application is itself built with PrimeFaces.

That scope separates it from PrimeFaces (see the PrimeFaces pages of this section, which start with the setup and continue with Ajax and forms, data components and PrimeFaces Extensions), which is a UI library: PrimeFaces gives you a data table and a dialog, OmniFaces gives you the missing @Param annotation, the validator that compares two fields, a handler that makes an Ajax failure show your error page, and a few output components (o:cache, o:tree, o:highlight) that render no widget markup of their own.

OmniFaces is organised by the kind of artefact it adds. The table lists the packages under org.omnifaces and the sections of this page that cover them; the showcase groups its examples the same way.

Source: OmniFaces home page and OmniFaces showcase

Three design choices explain how the library behaves. First, it is a WAR library: it is a web fragment with CDI extensions and Faces configuration that it registers by itself, and the jar belongs in WEB-INF/lib of each web application (Installing OmniFaces). Second, it keeps its own dependencies to a minimum: Bean Validation is optional, and the library bundles its own JSON encoder, XML helpers and cache. Third, it prefers the standard to the proprietary where the standard has caught up. Several ideas that OmniFaces offered first reached Faces itself: f:importConstants and f:websocket (both in Faces 2.3; o:socket of OmniFaces 2.3 came first), CDI injection into converters and validators (Faces 2.3, and managed=true in 4.0), and a CDI replacement for @ManagedProperty (jakarta.faces.annotation.ManagedProperty, covered on the backing beans page), which injects a value by EL expression and coerces it by the EL rules but, unlike @Param (@Param, @Cookie and @ContextParam: Injecting Request Data), has no Faces converter, validator or message. The OmniFaces documentation says so on the page of the feature concerned, and this page does the same: for every feature it states whether the standard now covers the case and when to reach for OmniFaces anyway.

OmniFaces is one jar without required third-party dependencies. In Maven, a Faces 4.1 application adds:

Source: OmniFaces: installation

Pick the artifact line by the Faces version of the target server, because the minimum versions change with the major version:

Source: OmniFaces: compatibility matrix and download

The 4.x and 3.x lines receive the bugfixes of 5.x but no new features. The 5.5.5 and 4.7.15 releases are dated the same day and carry the same fixes. A Faces 4.0 server (Jakarta EE 10) therefore stays on 4.7.15 until it moves to Jakarta EE 11, and a Faces 4.1 server uses 5.5.5. The one optional dependency worth knowing is Bean Validation (version 3.1 for 5.x), needed only for o:validateBean and FacesLabelMessageInterpolator.

Three rules about where the jar goes, from the project documentation:

On start-up the library logs one line that confirms it was found (INFO: Using OmniFaces version 5.5.5 in the scratch runs, from ApplicationInitializer).

The utilities that need a lifecycle position hook into the six phases (see the lifecycle page) as the diagram shows. The positions come from the Javadoc and from the source of the 5.5.5 sources jar; the sections below repeat them where they change behaviour.

Anything that reads a request parameter, @Param among them, runs when the bean that holds it is created, which is a different moment from all of the above: the first time a view or a class refers to the bean. @Param, @Cookie and @ContextParam: Injecting Request Data shows what that costs.

org.omnifaces.util.Faces is the class most people meet first. It is a set of static shortcuts that "flatten" the hierarchy of objects that you reach from FacesContext, plus a number of helpers that remove multi-line boilerplate: Faces.getRequestParameter(name) instead of the chain through the external context, Faces.redirect(...) that prepends the context path and URL-encodes its parameters, Faces.sendFile(...) that streams a download, Faces.getLocale() that never returns null. FacesLocal has the same methods with the FacesContext as first argument; use it in code that calls many of them, to look up the thread-local context once. The classes beside it follow the same pattern for a different part of the API:

Source: OmniFaces 5.5.5 API: Faces and OmniFaces showcase: Faces

Utils, Json and Xml in the same package are internal; the Javadoc says in as many words that their signatures can change without notice, so do not call them.

Adding a message by hand takes a client id, a severity, a summary and a detail, and a MessageFormat call if there are arguments. Messages reduces each case to one line. The summary is formatted with MessageFormat and the given arguments by default, so {0} is a placeholder (a literal quote or brace in the text has the usual MessageFormat rules).

Source: OmniFaces 5.5.5 API: Messages and OmniFaces showcase: Messages

Observed with the UtilsBean above: the three actions rendered Welcome back, reader! in h:messages, the pair The title Dune is already on the shelf (also on the h:message for="title" of the form) and Your changes were not saved, and Review saved for the builder (the detail Thank you, reader is added too, but h:messages shows the summary unless showDetail="true"). The flash message appeared on the redirected page, Book 42 added, which is what the flash is for (see the flash page). The methods exist per severity (Info, Warn, Error, Fatal) in the global, per-client-id and flash variants, with clear... methods and isEmpty() checks beside them.

Resource bundle keys. The shortcuts take the message text, not a bundle key, so an internationalised application sets a resolver once: Messages.setResolver(...) with an implementation of Messages.Resolver that looks the text up in the bundle for Faces.getLocale() (the Javadoc has the example). The resolver can be set only once, early (in a @Startup bean for instance, @Eager and @Startup). That example was not run; the standard way of putting localised messages on the page is on the messages page.

Standard Ajax decides what is re-rendered in the view: the render attribute of f:ajax lists the ids (see the Ajax page). When the bean knows better, org.omnifaces.util.Ajax adds to the list from Java, runs a script when the response has been processed, and passes data to that script. It works through the OmniPartialViewContext that the jar installs, so it needs nothing in the page:

Source: OmniFaces 5.5.5 API: Ajax and OmniFaces showcase: Ajax

In headless Chrome, two clicks on the button on Mojarra and on MyFaces updated form:mine (named in f:ajax render) and the other output outside the form (named only in the bean), both to 2; the script set window.result to Dune:2:false, that is the data from Ajax.data and OmniFaces.Ajax.validationFailed (new in 5.4: the value of FacesContext.isValidationFailed() for that response, so a script can react to a failed validation without reading the DOM). o:onloadScript ran its body on the initial load and after each of the two Ajax responses (three times), which is how to re-apply a jQuery plugin to markup that an Ajax response replaced. Other methods of the class are updateRow(UIData, int) and updateColumn(UIData, int) (the cell content must be wrapped in a container with a fixed id), load(library, resource) to add a script resource on completion, updateAll() and isExecuted(clientId).

Two limits to remember. The data values are encoded as JSON by the library’s own encoder, which supports numbers, strings, booleans, dates, arrays, collections, maps and (as a last resort) JavaBeans, so send plain values, and never put secrets in them: everything lands in the browser. And Ajax.update takes client ids, so an id inside a naming container needs its full path (form:mine), as everywhere else in Faces.

o:form (The o: Tags, Component by Component) complements this on the request side: it posts only the parts of the form that the Ajax execute list needs.

A bookmarkable page (see the view parameters page) usually declares f:viewParam in f:metadata, adds a f:viewAction or a preRenderView listener to load the data, and puts the loaded value into the bean in a method the framework calls at a particular phase. @Param collapses this: the request parameter is injected into the bean’s field, converted and validated, and is available in @PostConstruct.

Source: OmniFaces 5.5.5 API: Param and OmniFaces showcase: Param

The elements of @Param (all @Nonbinding, so they do not change which bean CDI injects):

Supported field types are String, every type with a Faces converter, List<T> and arrays (for repeated parameters, ?tag=a&tag=b gave [a, b]), and ParamValue<T> for a converted value that is not serializable: the bean is serializable, the ParamValue is converted again from the original parameter after deserialisation. A ParamValue always holds the submitted string beside the converted value (getSubmittedValue()), which is useful in a message.

What the scratch run showed (identical on Mojarra and MyFaces):

CDI creates beans lazily, at the first use. That is wrong for a bean that must do something at a defined moment: warm a cache when the application starts, register a listener, or prepare data when a particular URL is requested. The old Faces @ManagedBean(eager = true) did the first; CDI has no equivalent, and @Eager fills the gap for five scopes.

Source: OmniFaces 5.5.5 API: Eager, Startup and OmniFaces showcase: Eager

On Tomcat with Weld and Mojarra the log showed BookshelfStartup created at application start right after the line Using OmniFaces version 5.5.5 and before Mojarra reported initialising the context: the startup bean is created before Faces itself is started. The Javadoc says that FacesContext is not available in the @PostConstruct of @Eager beans declared without a viewId; inject the HttpServletRequest, HttpSession, ServletContext or other beans instead. EagerPage created for /eager.xhtml appeared on the first request for /eager.xhtml. The @Startup that OmniFaces defines is a stereotype for @Eager @ApplicationScoped; the identically named jakarta.ejb.Startup needs an EJB container and turns the class into a session bean, so watch the import. The scopes page has the same bean in a different role (the application scope section).

The view parameters page of this section (view parameters and view actions) explains f:viewParam and f:viewAction and the traps in them. OmniFaces offers variants that avoid several of those traps, o:viewParam and o:viewAction, and a tag for what to do on a failure. The two components are drop-in: change the prefix from f: to o:.

Source: OmniFaces showcase: viewParam, viewAction and viewParamValidationFailed

The same page written with the standard tags (f:viewParam and f:viewAction with the same attributes) is the control. Both pages were requested with different query strings and then posted back, on Mojarra and on MyFaces:

What the table shows is what the o: tags are for:

Behind the tags, a page that is reached by path instead of query parameters (/book/123) uses o:pathParam and @Param(pathIndex) with FacesViews (FacesViews: Extensionless URLs, MultiViews and Dynamic Routes). Three more input components belong to the same family and were only read, not run: o:hashParam (the fragment after #, kept in sync with a model value by window.onhashchange and every Ajax response), o:scriptParam (the result of a JavaScript expression that the client evaluates and sends, for the time zone offset or the screen width) and o:componentIdParam (renders only the components named by a GET parameter, for mashups). All three put client-controlled data in the model; validate it like any request parameter.

Choosing. A single lookup of a record by id is a good fit for @Param (@Param, @Cookie and @ContextParam: Injecting Request Data). A page that must reject a bad or absent parameter before anything runs, and that posts back, is a good fit for the OmniFaces tags above.

Bean Validation (see the Bean Validation page) validates one property at a time during Process Validations, because that is how Faces works: a model is updated only after all inputs are valid. Two needs fall outside: switching validation off for one button, and validating a constraint that spans several properties of one object. o:validateBean serves both, and the o:validateXxx components do the same for plain inputs without a bean.

A converter turns a submitted string into an object and back (see the converters page). Most of the OmniFaces converters exist to remove the need to write one. Each has a converter id (omnifaces.SelectItemsConverter) for the converter attribute and, since 4.5, a tag (o:selectItemsConverter) for nesting in the component.

Source: OmniFaces showcase: SelectItemsConverter and OmniFaces VDL: o:selectItemsConverter

The one converter that nearly every project needs is SelectItemsConverter. The usual dropdown over entities fails without a converter, because a submitted string cannot become a Book; the usual workaround is a converter that queries the database by id on every postback. The scratch page:

Source: OmniFaces 5.5.5 API: SelectItemsConverter

Observed on both implementations, with Book as a record with title, author, year and genre:

What this teaches about SelectItemsConverter and toString():

An ImplicitNumberConverter limit on user input. The scratch run showed that the converter fails on input that the other converters accept. When the submitted text lacks the symbol, the converter builds the string with Matcher.replaceAll using the submitted value as the replacement; a submitted $1 (for a field with currencySymbol="€" or for a percent field) ended in HTTP 500 on both implementations, with IndexOutOfBoundsException: No group 1 in the log. On MyFaces, a currency field also failed for ordinary input: 12.50 gave '¤12.50' could not be understood as a currency value, the generic currency sign in place of the symbol, and $12.50 gave HTTP 500 for the same replaceAll reason, while Mojarra accepted both. The percent case worked on both. Treat the currency mode as unverified on MyFaces, and write your own converter, or validate the text first, when a currency field is public. This is an observation on 5.5.5, not documented behaviour; test it again on the version you use.

With PrimeFaces, the converter works as in the Javadoc: p:selectOneMenu with omnifaces.SelectItemsConverter, and p:pickList with <o:converter converterId="omnifaces.ListConverter" list="#{pickBean.picks.source}"/>, converted Cosmos back to the right instance and the picked list to a one-element target list on Mojarra and on MyFaces (OmniFaces Next to PrimeFaces).

OmniFaces 5.5.5 declares 72 tags under the o: prefix (the VDL documentation lists them all with their attributes). They fall into groups, and three of them are the subject of the earlier sections (the validators, the converters, and the view parameter family). The table is the map; the subsections that follow detail the ones that are used all the time, with what the scratch run showed.

Source: OmniFaces 5.5.5 VDL documentation and OmniFaces showcase

Tag handlers work when the view is built, not at render time. The ones that matter most:

OmniFaces ships 81 EL functions: static methods wrapped as functions for use in value expressions. In 1.x to 4.x they lived under a second prefix, of:, with its own namespace; in 5.0 they merged into o: (Installing OmniFaces). The old code is rewritten by a rename: #{of:formatDate(...)} becomes #{o:formatDate(...)}. They are grouped by the class in org.omnifaces.el.functions:

Source: OmniFaces VDL documentation: library overview, with the functions and OmniFaces showcase: functions

Results from the scratch page consts.xhtml above, identical on both implementations:

Three of the functions are for security-sensitive places, and one is a trap:

Prefer the implicit objects and the plain EL where they do the job; the OmniFaces Javadoc itself says that the o: form of the Faces functions is poor practice next to #{request.contextPath} or #{faces.development}.

The standard h:graphicImage shows a file served as a Faces resource. An image from a database (a book cover) needs a servlet. o:graphicImage accepts a byte[] or an InputStream in its value, and the library serves it through a resource URL, without a servlet. A bean whose methods return the image bytes is marked @GraphicImageBean, a stereotype that makes it a named application scoped bean (the annotation implies @Named and @ApplicationScoped).

Source: OmniFaces 5.5.5 API: GraphicImageBean and OmniFaces showcase: graphicImage

The rendering on Mojarra and on MyFaces: each img had a src of the form /bookshelf/jakarta.faces.resource/CoverBean_cover.png.xhtml?ln=omnifaces.graphic&v=0&p=1 (the method name and the argument become the resource name and the p parameter), dataURI="true" produced src="data:image/png;base64,...", and #{o:graphicImageURL('coverBean.cover(2)')} printed the URL form. Fetching a URL answered 200 with Content-Type: image/png, a one-week Expires and Last-Modified in 1970 (no lastModified attribute given); lazy="true" defers evaluating the method until the image request, and type, lastModified, width and height are available. An unknown bean or method in the URL (OtherBean_secret.png.xhtml) answered 404, and so did a non-numeric argument for a long parameter.

The security consequence. The Javadoc states that @GraphicImageBean "basically enables endusers to invoke any public method returning a byte[] or InputStream on the bean by just a HTTP GET request." The scratch run fetched ...CoverBean_cover.png.xhtml?ln=omnifaces.graphic&v=0&p=3 with no session cookie and received the image, and any p that the method accepts can be requested. That makes every public image method of the bean a public, guessable URL. Rules that follow:

Before @GraphicImageBean (OmniFaces 2.5) the bean could be any @Named @ApplicationScoped bean; the Javadoc explains that after a server restart the images stop working until a Faces page has referenced the method once, because of exactly the security restriction above.

The standard ExceptionHandler mechanism and the way an Ajax failure ends up as a blank page are explained on the exception handling page, which also shows OmniFaces' handlers in use (OmniFaces FullAjaxExceptionHandler); the results of that page are not repeated here. What the library offers, in one place:

Source: OmniFaces showcase: FullAjaxExceptionHandler and OmniFaces 5.5.5 API: FullAjaxExceptionHandler

The properties that the earlier page verified, on Mojarra 4.1.17 and MyFaces 4.1.4: the Ajax response replaces jakarta.faces.ViewRoot with the error page and answers HTTP 200; the filter unwraps the exception so that a mapping by exception type matches on MyFaces too; an error page that sets its own status made Mojarra answer 500 and leave the browser with a blank page. The error page shows a reference number (#{requestScope['org.omnifaces.exception_uuid']}) and nothing else: no message, no trace.

Six servlet filters in org.omnifaces.filter; none is registered unless said so, and each is mapped in web.xml like any filter.

Source: OmniFaces 5.5.5 API: org.omnifaces.filter and the performance page

The compression and cache control filters are discussed with their measurements on the performance page. Mind one interaction there: OmniFaces' CacheControlFilter disables caching for what it covers, so map it on the views and not on the resources.

A ResourceHandler produces the URLs of scripts, styles, images and fonts and serves them (see the resource handling page). OmniFaces ships several, wrapping each other like all handlers (the one registered later wraps the earlier ones).

CorsAwareResourceRenderer (5.0) is not a handler but a renderer, and is registered automatically. It adds crossorigin to the script and stylesheet elements whose URL is on another origin (default anonymous, changed with org.omnifaces.DEFAULT_CROSSORIGIN) and, when the resource is a CDNResource, an integrity hash computed from the local content. Before 5.0 CombinedResourceHandler set these attributes itself, and forced CORS mode on same-origin resources, which in 5.5.1 was corrected because it broke jQuery 4 loading.

The three handlers that need configuration, as run in the scratch application:

Source: OmniFaces 5.5.5 API: CDNResourceHandler, UnmappedResourceHandler and VersionedResourceHandler

The rendered head, on Mojarra (MyFaces rendered the same, with a ;jsessionid=... path parameter on the first request of a client without a cookie):

The local style sheet has the version, the unmapped URL (no .xhtml) and its relative url("images/bg.png") resolved to /jakarta.faces.resource/css/images/bg.png, which answered 200; the CDN resources have the CDN URL and crossorigin="anonymous" and, as the Javadoc of the renderer says, no integrity because the CDN handler does not know the remote content. Order matters, as the Javadoc says: a handler registered after CombinedResourceHandler wraps it, and UnmappedResourceHandler must come after the others or the combined resources keep their mapped URLs.

Three security notes:

The push page compares f:websocket and o:socket in a table and shows the sender API; this section adds the other two components and the results of running them. Three transports share one sender API, @Inject @Push PushContext, selected by the type of the annotation:

Source: OmniFaces showcase: o:socket, o:sse and o:notification

Observed in headless Chrome, on Mojarra and on MyFaces: a click on a button with an Ajax action that called reviews.send(...) made the onmessage function receive the message, and likewise for alerts.send("new-review") on the SSE page. A message sent as a String arrives as a JSON string, "{\"book\": ...", so send an object (a map or a bean, encoded by the library’s JSON encoder) when the page should receive structured data. The rendered page registers each channel as reviews?<uuid>, a channel name plus a random token, and the client’s OmniFaces.Push.init call.

FacesViews serves Facelets at URLs without an extension, selected by directory scanning, with no FacesServlet mapping required. Faces 4.0 has an extensionless mapping of its own (see the project setup page and the configuration page), which maps /index to /index.xhtml and nothing more. FacesViews adds the redirects, the path parameters of MultiViews and, since 5.5, dynamic route segments.

Zero configuration: views below /WEB-INF/faces-views/ become public as /name. For the other places, org.omnifaces.FACES_VIEWS_SCAN_PATHS; its value /*.xhtml/* scans every .xhtml file below the web root (not WEB-INF, META-INF or resources) and turns MultiViews on. The scratch application:

Source: OmniFaces 5.5.5 API: FacesViews and OmniFaces showcase: ExtensionlessURLs

The relevant context parameters are FACES_VIEWS_EXTENSION_ACTION (REDIRECT_TO_EXTENSIONLESS, SEND_404, PROCEED), FACES_VIEWS_PATH_ACTION (default SEND_404 for views requested by their path below a scanned directory), FACES_VIEWS_SCANNED_VIEWS_ALWAYS_EXTENSIONLESS (links always without extension), FACES_VIEWS_ENABLED and FACES_VIEWS_LOWERCASED_REQUEST_URI. A link to a dynamic route needs <o:pathParam name=... value=.../> for every segment, because the rendered URL cannot contain the square brackets. A dynamic-route directory name must be unambiguous: two different segment names under one parent, the same name twice in one path, or an unbalanced bracket fail the deployment. A literal sibling directory always wins over the dynamic one (an organisation whose id is settings is unreachable).

Filters and security. FacesViews reaches a view in two ways: by wrapping the request and continuing the chain (the MultiViews /search/dune/2 case) or by forwarding (dynamic routes and the redirects). A forward bypasses the filters that are mapped for the default REQUEST dispatcher. The scratch run mapped a @WebFilter("/*") that set a header:

This is the documented behaviour (the Javadoc says the FacesViews filter is first in the chain by default), and the consequence is the point: an authentication or authorisation filter, a CSRF filter or a security-headers filter that is mapped as usual can be skipped on part of the application. Either set the parameter, or protect by security-constraint (which the container applies before any of this, 403 above), or declare the filter for FORWARD too. Check every protection you rely on with a request to a dynamic route. Also keep in mind that the constraint pattern must match the URL as FacesViews serves it: /admin/panel.xhtml does not constrain /admin/panel (the pitfall of the security page); use /admin/*.

Uploads and media belong outside the web application, and the default servlet cannot serve them. org.omnifaces.servlet.FileServlet is an abstract servlet that does the work properly: ETag, If-None-Match, If-Modified-Since, Range and If-Range (needed by media players to seek and by downloads to resume). You override getFile(request):

Source: OmniFaces 5.5.5 API: FileServlet and OmniFaces showcase: FileServlet

The run, on Mojarra: /media/readme.txt answered 200 text/plain; a missing file 404; /media/ 400 (the IllegalArgumentException); /media/..%2f..%2fetc/passwd 400 from Tomcat before the servlet; a request with Range: bytes=0-99 for a 20,000-byte file answered 206 with Accept-Ranges: bytes. The default response also carried Cache-Control: public,max-age=2592000,must-revalidate (30 days, public) and Content-Disposition: inline.

Two changes follow for anything that is not a public cover image. The servlet serves exactly the file you return and does no confinement of its own, and the Javadoc example builds new File(folder, pathInfo); the class above resolves, normalises and checks the prefix, which is the minimum (also resolve symbolic links with toRealPath() if the folder may contain any; not run). And a response that is public for 30 days may be stored by shared caches, so override getExpireTime and the headers for files that only some users may see, and authorise inside getFile (return null for 404, throw IllegalArgumentException for 400). Also override isAttachment and getContentType for user-supplied files, so that an uploaded HTML or SVG file is delivered as a download or with a safe content type and not as active content of your origin (the upload validation section).

OmniFaces 5.0 added three tags under xmlns:sec="omnifaces.security" that render their content by the state of the Jakarta Security SecurityContext: <sec:authorize role="ADMIN"> (or anyRole="ADMIN, EDITOR", or allRoles="ADMIN, AUDITOR"; exactly one of the three), <sec:isAuthenticated> and <sec:isAnonymous>. var="isAdmin" on authorize exposes the result as a variable for several uses. If no SecurityContext is available a warning is logged and nothing is rendered (it fails closed).

Source: OmniFaces showcase: AuthorizeTagHandler and OmniFaces VDL: sec:authorize

These were read in the documentation and not run. They are tag handlers, evaluated when the view is built like JSTL tags (the JSTL page), so the decision is made once per view build and not on each render. They hide user interface elements; they authorise nothing. Protect the targets with a security-constraint, @RolesAllowed or the checks of the service layer (the roles section), and treat the tags as a convenience that keeps the menu honest.

The two libraries do not compete: PrimeFaces supplies widgets, OmniFaces supplies the plumbing, and the OmniFaces showcase is a PrimeFaces application. The scratch page pf.xhtml used PrimeFaces 16.0.0 and OmniFaces 5.5.5 together on Mojarra and on MyFaces:

Source: OmniFaces 5.5.5 API: ListConverter, PrimeFaces 16 documentation: PickList and SelectOneMenu

An Ajax post of the form (PrimeFaces p:commandButton, jakarta.faces.partial.render=@all) converted the p:selectOneMenu value with omnifaces.SelectItemsConverter to the Cosmos record, converted the p:pickList target with o:converter and omnifaces.ListConverter to a one-element list, and failed with Differ (p:messages) when the two p:inputText values were different and passed when equal (o:validateEqual). The head contained the PrimeFaces scripts and omnifaces.js side by side. Where both offer something similar, the division is:

The cost of mixing is in the details. Both libraries replace parts of the framework (render kit, partial view context), so a third-party extension that does the same needs checking. PrimeFaces and OmniFaces both ship scripts and styles for the head, which CombinedResourceHandler can combine (the measured figures are on the performance page). And a strict Content-Security-Policy applies to both: the PrimeFaces CSP behaviour is on the security page; the inline scripts of the OmniFaces components are in The o: Tags, Component by Component.

OmniFaces supports both implementations (since 5.4 it also declares itself compatible with Mojarra 5.x and MyFaces 5.x, the Faces 5.0 line); the differences observed in this section’s runs (Mojarra 4.1.17, MyFaces 4.1.4, OmniFaces 5.5.5) are small but real:

Everything else in this page behaved the same on both: Faces and Messages, @Param, @Cookie, @ContextParam, the converters other than the one above, the multi-field validators, o:form, o:link, o:url, o:highlight, o:outputLabel, o:skipValidators, o:ignoreValidationFailed, o:enableRestorableView, o:graphicImage, the EL functions, Ajax, @RateLimit, o:socket and o:sse separately, FacesViews and the resource handlers.

The OmniFaces release notes (the "What’s new" page of the showcase) and the @since tags of the Javadoc give the history. The table lists what matters for a Faces 4.1 application; older entries show where the features of the earlier sections came from, which helps when you meet them in old code.

Source: OmniFaces showcase: What’s new and OmniFaces home page

How this interacts with Faces versions: OmniFaces 5 needs Faces 4.1, so it cannot be used on a Faces 4.0 server (Jakarta EE 10) whose container does not provide Faces 4.1; the 4.7.x line is the right one there, and its tags and classes are the same as far as the table shows, except for the namespace and the 5.0 additions (RateLimit, sec:, o:sse, o:notification, o:lazyPanel, o:compositeConverter, FacesLabelMessageInterpolator instead of the old name). Faces 5.0 is still a milestone; the 5.4 release notes only promise compatibility with its implementations. The upcoming Faces 5.0 is planned to drop the old XML namespaces (see the versions page), and OmniFaces 6.x will drop its URL namespaces as well.

None of the eight books that this section consulted covers OmniFaces 4 or 5: the newest of them, the second edition of the PrimeFaces cookbook, dates from May 2015, and the others from 2004 to 2014. They solve by hand, or by other libraries, problems that OmniFaces now solves, and some of what they teach is no longer possible or no longer safe. Taking the topics that the books treat and that this page covers:

Security first, then correctness.