Thursday, April 12, 2018

OmniFaces 3.1 adds MessagesKeywordResolver and SourceMapResourceHandler

OmniFaces 3.1 has been released!

Next to a bunch of utility methods, this version adds a MessagesKeywordResolver and a SourceMapResourceHandler. This version also deprecates WebXml.INSTANCE and FacesConfigXml.INSTANCE with as replacement the WebXml.instance() and FacesConfigXml.instance() respectively via an interface instead of an enum. This way they can easier be mocked during unit testing.

You can find the complete list of additions, changes and fixes at What's new in OmniFaces 3.1? list in showcase.


Non-Maven users: download OmniFaces 3.1 JAR and drop it in /WEB-INF/lib the usual way, replacing the older version if any.

Maven users: use <version>3.1</version>.



This is the first addition which utilizes a brand new JSF API: the Component Search Expression Framework. The MessagesKeywordResolver basically adds support for @messages in <f:ajax render>.

<h:inputText id="input1" ... />
<h:message id="m_input1" for="input1" />
<h:inputText id="input2" ... />
<h:message id="m_input2" for="input2" />
<h:inputText id="input3" ... />
<h:message id="m_input3" for="input3" />
<h:commandButton ... />
    <f:ajax execute="@form" render="@messages" />

This way, only the message components are updated on submit. This is more efficient than e.g. render="@form" which unnecessarily also updates the input and button components.


If you've more than often debugged minified CSS/JS resources in browser developer toolset, you'll probably ever have heard of "source maps", usually referenced by a code comment somewhere in the bottom of the minified file, such as /*# */. To the point, these files represent the mapping between the minified version and the unminified version, so that the browser developer toolset can after downloading the source map file automatically unminify the minified version, whereby the original variable names are substituted back.

Very useful, particularly for minified/uglified JS resources. Unfortunately, resolving the source map files doesn't always work well with suffix-mapped JSF resources which uses a virtual URL pattern with /javax.faces.resource/ prefix and .xhtml suffix. The average CSS/JS compiler/minifier also has no knowledge about the way how JSF resources are being served. Fortunately, source map URLs can be set by a SourceMap header on the response of the CSS/JS resource. This is thus exactly what the SourceMapResourceHandler does.

It can be installed in the JSF application by below entry in faces-config.xml:


It will by default asusme that the source map files are by the build tool placed in the same folder as the minified resources and have a .map extension appended to the resource name. So it will work when you have a some.js resource and a file in the same folder. In case it's by the build tool being placed in a subfolder as in sourcemaps/, then you can use the below web.xml context parameter to instruct the SourceMapResourceHandler on this.


How about OmniFaces 2.x and 1.1x?

2.x is basically already since 2.6 in maintenance mode. I.e. only bugfix versions will be released. It's currently already at 2.6.9, also released today. As long as you're still on JSF 2.2 with CDI, you can continue using latest 2.6.x, but it won't contain new things introduced in 3.x.

1.1x is basically already since 2.5 in maintenance mode. I.e. only bugfix versions will be released. It's currently still at 1.14.1 (May 2017), featuring the same features as OmniFaces 2.4, but without any JSF 2.2 and CDI things and therefore compatible with CDI-less JSF 2.0/2.1.

Maven download stats

Here are the 2018's Maven download stats so far:

  • January 2018: 14646
  • February 2018: 14786
  • March 2018: 18059

Below is the pie of March 2018, 3.0 is already on 9%:

Saturday, April 7, 2018

Do not use org.glassfish Mojarra 2.4.0!

Look, there's a Mojarra 2.4.0 in Maven Central!

What is this? Is JSF 2.4 already there?

No, JSF 2.4 is not there. Technically speaking, Mojarra 2.4.0 represents the latest state of the master branch as it was during the transfer from Oracle to Eclipse. That transfer took place when JSF 2.3 specification was already released and JSF 2.4 specification has still to be started yet. JSF 2.4 is far from being a beta, let alone a reasonable snapshot. And yet there is a Mojarra 2.4.0 in Maven instead of e.g. a Mojarra 2.4.0-M1. As per the agreement between Oracle and Eclipse, it was necessary to release the latest work on Mojarra under Oracle's umbrella into Maven Central before the transfer to Eclipse was completed, and this had to be done without making any code modifications, even pom.xml version changes are not allowed and thus the version couldn't be modified. And later Eclipse will do the same after the transfer is completed so that the integrity can be validated by the public. Using version "2.4.0" is indeed way too confusing for the public, because does actually not at all represent a real "2.4.0" version, but it is what it is.

In other words, you should not use it. Mojarra 2.4.0 is basically somewhere in between Mojarra 2.3.3 and 2.3.4. A few days later, Mojarra 2.3.4 was released. Use this instead.


Or, if there's already a newer 2.3.x version available, obviously use that instead.

After the transfer to Eclipse, we'll as first step change the package name from javax.faces to jakarta.faces (and thus also the Maven coordinates) and bump the version to 3.0 for Jakarta EE 9. In other words, there will never come an official release of JSF 2.4.