I recently found myself in need of having two different Testcontainers communicate with each other. To someone more familiar with Docker, the solution might have been more obvious, but, alas, I am not that man. :P After asking in the Testcontainer Slack, I got a pointer, so I thought I’d share it here in case it might help someone else.

As 2023 comes to a close, I want to take a slightly different approach to my Christmas greetings. I’d like to share with you a Christmas carol, and the story behind it.

The poem, written by Henry Wadsworth Longfellow, explores the contrasting despair in his heart against the hope of Christmas. Having lost his wife to a fire, and having his son critically wounded in the Civil War, Longfellow struggled with his faith which spoke of "peace on earth, goodwill to man" while he watched the injustice and violence in the country at war around him. At the end of the poem, written on Christmas day in 1863, he concludes with the confession that, while things seem bleak,“God is not dead, nor doth He sleep; The Wrong shall fail,The Right prevail, With peace on earth, good-will to men.”

With wars and violence all over the globe, that statement is still true today. One day two thousand years ago, Jesus became a human, in the form of a tiny infant, as the final step in righting wrongs and prevailing over evil finally and fully. Christmas, then, points to Easter, and should serve as a reminder that, while evil does seem prevalent now, the day is coming when God finally says "Enough!" and declares judgment. My prayer, as it is every Christmas season (and, indeed, every day) is that this year will be the year you see Christmas as more than a chance for time off and getting and receiving gifts, but as the offering of the greatest gift of all: salvation through Jesus Christ.

Merry Christmas!

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.