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.

Jakarta EE 9.1 was released today, which now lets developers use -- officially -- Java 11 with the shiny new Jakarta EE namespace introduce in EE 9. So what does a simple Jakarta EE 9.1 REST project look like? I'm so glad you asked. :)

As part of some of my recent work, I've gotten some exposure to some Microprofile specs I've not had the opportunity or need to use. One of those is Fault Tolerance . I was curious to see it action, so I've cobbled together this simple example that demonstrates some of that spec's features, namely retries and fallback.

Obviously, web apps need to be secured. If you're brave (and some might say foolish), you can roll your own security. Unless you have compelling reasons to do so, however, you probably shouldn't. Almost as if by design (nyuk nyuk), Quarkus makes it easy to use any OpenID Connect server. One such server is Keycloak, an open source offering also from Red Hat. If your experience is like mine, though, securing endpoints makes testing a touch more complicated. In this post, I'd like to present and walk through a complete example of a secured Quarkus app, using Keycloak, JUnit and Wiremock.