MyFaces 4 on WildFly

For several years now, WildFly has supported the ability to install and use different Jakarta Faces (Faces) implementations, either across every application deployed to the server, or for a specific application only. We supported running either Mojarra and MyFaces, with versions running all the way back to 1.2. With the move to Jakarta EE 10, however, that feature was temporarily broken simply because there was not a 4.0-compliant version of MyFaces available by the time we were ready to ship. That has changed now, though, as has the manner in which we support changing the implementations. In this short post, I’ll show you how that works starting in WildFly 29.

There are two major changes to Jakarta Faces support that will come with WildFly 29. The first is really a practical matter: any Faces implementation that is not 4.0-compliant is simply not permitted. This is due to the namespace change that came in Jakarta EE 9/10. Those older libraries are just not binary compatible.

The other change, and probably the most important, is that, while the mechanism for changing implementations ships in WildFly, the actual implementation change code and configuration is now shipped in an external feature pack. To explain all of this, you’re about to get a bit of a dive into WildFly internals.

I have no hard data on this, but I would imagine the many, if not most, WildFly users install the application server using a downloaded archive. If I’m right, the concept of a feature pack might be unfamiliar to many users. While a full discussion is outside our scope here, a feature is, roughly, …​ a pack that contains a feature. :) It’s an archive that includes code, configuration, etc. and instructions for the tooling on how to install the feature. WildFly itself is actually built using feature packs. We just package up the output of that process in the zip and tar downloads you see on the site.

It is possible, however, to build your very own stripped-down server using the same tool we do: Galleon. Again, I won’t dive too deep here, but to build a server that exposes Jakarta REST endpoints, but doesn’t include, say, EJB, you could execute something like this:

Pretty cool, but why is this important? Well, prior to WildFly 29, in order to install a given feature pack, you had to provision your server using Galleon. Perhaps not a very big deal, but if you have an existing server, then discover a feature pack you’d like to try, you had to provision a new server, migrate configs, etc. Not a lot of fun, though I could be overstating that. Regardless, as of 29, you can now install a given feature pack into an exising WildFly installation. To demonstrate that, we’ll install MyFaces support into an existing provisioning of WildFly 29.

To demo this, we’ll use the just released WildFly 29 Beta:

We can now deploy any Jakarta Faces application, and you should see something like this:

And there you have it. A quick introduction to a couple of new changes coming WildFly soon, and a very brief introduction to a very powerful related tool. If you’re a MyFaces user, please try out the feature pack and let us know if you have any issues with the integration!