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