A friend of mine is a very good Angular developer. For a project he’s been asked to help with, though, he finds himself needing to do some backend work. Since that’s a bit outside his wheelhouse, he asked me for advice. In this post, I’ll write up what I told him in case it might be of use to someone else.
One of the toughest challenges facing a mature product like WildFly is adding features without breaking existing users. It’s especially difficult when that project serves as the foundation for a commercial product downstream that requires a higher degree of stability. While WildFly is a wholly independent project, it’s not completely immune to concerns that EAP may have with regard to API stability, long term support, etc. That has made it difficult at times to change WildFly, though efforts like WildFly Preview have certainly helped.
With that in mind, I’d like to draw your attention to a project WildFly/EAP engineer extraordinaire, Paul Ferraro recently announced on the wildfly-dev email list. You can click through to the list archive, or read a more nicely-formatted copy of the email below. Either way, we would greatly value any feedback you might provide.
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.
With the release of WildFly 28, we’ve made a few changes to our supported telemetry libraries that are worth noting. In this post, I’ll give a quick overview of those changes.
Back again with another Testcontainers example. This time, though, the environment is a bit different. We’ll be looking at a Jakarta EE application using WildFly and MicroProfile Reactive Messaging (MP RM), and we’re going to test it using Arquillian and Testcontainers. Let’s get to it. :)
I have written a few posts about using Quarkus with Testcontainers, Flyway, and jOOQ. Since posting those, I’ve learned some new tricks that have changed how I integrate the various tools. In this post, I’d like to share a complete example that shows how use Quarkus, Quarkus Dev Services, Testcontainers, and Flyway together for a zero (ish) local config setup.
A big part of the testing we do on WildFly involves in-container testing, for which we use Arquillian. It’s a great tool when it works right, but sometimes things don’t. When that happens, I find it helpful to examine the archives that the tests produce. Fortunately, Arquillian makes that easy if you know that magic words, and they’re not easy to find, so I’m going to fix that here. :P
In a recent post, I showed how one could fairly easily test your Quarkus application against a Testcontainers-managed Postgres database. While that works great, my set up is a little more complex, and I found the solution lacking. In a nutshell, as part of my build, I use Flyway with H2 to create a schema, then jOOQ’s code generation against H2 to create the needed classes. That all worked well enough until I found some types that didn’t quite map correctly against newer versions of H2 (a security issue necessitated the update), so I decided I should finally make use of the same database from start to finish. In this post, I’ll show how I did it.
In a project I’ve been working on, I’ve been targeting PostgreSQL, but testing with H2. While that works, I’m a big fan of having the test environment match production as much as possible. That said, I don’t like to have external system dependencies for tests, such as requiring having a database installed. That’s where Testcontainers comes in. In this post, I’ll look at how I integrated Testcontainers into my Quarkus+jOOQ project
To all my readers, I’d like to wish a merry Christmas, and a happy new year. In a world seeking hope, my prayer is that each of you would find real, lasting hope, in the birth the baby we celebrate today, Jesus Christ, Emmanuel, God with us.

(Image source. Thanks, Dr. Mounce :)