Blog Articles

thorntail

In this article, I’ll give you a quick tour of how to use the new MicroProfile Starter (Beta) site to generate, download, and build a Maven-based MicroProfile project with just a few clicks. Using this online project generator, you choose the MicroProfile version and server (such as Thorntail) that you want your project to be based on. Then you’ll be able to choose what example code to include in your project to see how to use the APIs that are part of the MicroProfile specifications such as Config, Health Check, Metrics, CDI, and more.

A Java runtime environment should be able to run compiled source code, whereas a development kit, for example, OpenJDK, would include all the libraries/binaries to compile and run the source code. Essentially the latter is a superset of the runtime environment. More details on OpenJDK support and lifecycle can be found here.

Red Hat ships and supports container images with OpenJDK for both Java 8 and 11. More details are here. If you are using Red Hat Middleware, the s2i images shipped are also useful to deploy, for example, on Red Hat Openshift Container Platform.

Note that Red Hat only provides OpenJDK-based Java 8 and 11 images. With that said, there will certainly be situations where developers would like to create their own Java runtime images. For example, there could be reasons such as minimizing storage to run a runtime image. On the other hand, a lot of manual work around libraries such as Jolokio or Hawkular and even security parameters would need to be set up as well. If you’d prefer not to get into those details, I would recommend using the container images for OpenJDK shipped by Red Hat.

By now you have probably heard of Eclipse MicroProfile (MP). It is a community-driven initiative to define specifications for enterprise Java microservices. MicroProfile is only two years old, yet it has delivered eight innovative specifications and is evolving fast. It provides metrics, API documentation, health checks, fault tolerance, distributed tracing, and more. With it, you can take full advantage of cutting-edge cloud-native technologies and do it in a vendor-neutral fashion!

For developers familiar with Spring Boot, we have prepared this article, which compares the basics of developing applications with Spring Boot and with MicroProfile. We wrote two applications, one with each solution. In this article, we will go through the differences between them. You can find the source code for both projects on GitHub.

For the MicroProfile application, we use Thorntail (formerly know as Wildfly Swarm), but except for the setting up part, Open Liberty, Payara, TomEE, or any other implementation would look exactly the same.

Throughout this article, we assume you know Spring Boot and we focus on what is different in MicroProfile.

Thorntail is the new name for WildFly Swarm, and bundles everything you need to develop and run Thorntail and MicroProfile applications by packaging server runtime libraries with your application code and running it with java -jar. It speeds up the transition from monoliths to microservices and takes advantage of your existing industry standard Java EE technology experience.

At the recently concluded Microsoft Ignite 2018 conference in Orlando, I had the honor of presenting to a crowd of Java developers and Azure professionals eager to learn how to put their Java skills to work building next-gen apps on Azure. Of course, that meant showcasing the technology coming out of the popular MicroProfile community, in which Red Hat plays a big part (and makes a fully supported, productized MicroProfile implementation through Thorntail, part of Red Hat OpenShift Application Runtimes).

During the last three months, there have been some changes regarding Eclipse MicroProfile at Red Hat. If you haven’t been following the details, this post recaps what’s changed and introduces Thorntail and SmallRye.

Bye-bye WildFly Swarm! Hello Thorntail!

You may have missed this important news. Our MicroProfile implementation changed its name two months ago.

After a lot of feedback from the community, we decided to rename “WildFly Swarm” to Thorntail. While the former name was nice, we found that the “Swarm” term was a bit overloaded in the IT industry and could be confusing. It’s the same for the “WildFly” part; sharing this name with our Java EE application server was a source of confusion for some users, making them think it was a subproject of WildFly.

Launched nearly two years ago, the Eclipse MicroProfile project is moving fast with four releases and eight subspecs having at least two implementations each. Because it’s a fast moving target, this post tries to give an overview of MicroProfile 1.3, which was released on September 30th, and helps you to get started with the specification.

Every developer has the goal of building the most resilient application possible. Due to the distributed nature of microservices, resiliency and handling failures gracefully is mandatory. The Java ecosystem has some nice frameworks for fault tolerance, such as Hystrix or Failsafe. However, none of these provide a standard API, so using them means your application will be tightly coupled to that framework. The primary motivation for the MicroProfile specifications is to provide standard APIs that eliminates the tight coupling and improves deployment flexibility. This article will describe the main features of the MicroProfile Fault Tolerance specification, and then demonstrate how it was implemented in WildFly Swarm, the Red Hat MicroProfile implementation.

A previous article described the specifications in the Eclipse MicroProfile 1.2 release and the benefits for Java-based cloud-native applications. This article shows how software developers writing Java-based microservices can leverage those specifications to take advantage of the management capabilities provided by Red Hat OpenShift.