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 :)

Earlier in the summer, I wrote some about the addition of OpenTelemetry support in WildFly. With the release of WildFly 25, that support is now official and in the wild. With 25 behind us, we start looking at 26, and my next effort will be to integrate Micrometer metrics into the server. In this post, we’ll take a look at what that might mean, as well as presenting a way to take an early look.

Most people know Quarkus as a great way to build fast, scalable microservices. What many may not be aware of, however, is that Quarkus can also be used to build command line applications as well. In this post, we’ll take a look at how we can leverage the Quarkus ecosystem we already know to build a command line utility quickly and easily.

In a recent post, I worked through setting up OpenTelemetry support in your Jakarta EE application. Since that time, I’ve put quite a bit of work into integrating that support, as teased in the post, into WildFly. In this post, I’d like to provide an update on what that WildFly support currently looks like, and put out a request for feedback.

Knowing what’s going on in your microservices deployment is extremely important when something goes wrong. In a distributed system, though, it can be difficult to know where things have gone wrong. That’s where a tracing system such as OpenTelemetry can be immensely valuable. In this post, we’ll build two simple services, one of which calls the other, and trace the execution from end to end.