Continuing with its quarterly delivery model, Wildfly 16 was released last month, closing or resolving almost 200 issues, feature requests, and bugs. Included in this release was Galleon, a provisioning tool for constructing custom-tailored Wildfly servers, compatibility with JDK12, as well as several enhancements to messaging, and clustering support.
Java application servers often ship with support for several different features and APIs, some of which an application might or might not use. The WildFly team recognized this problem and rather than having a "one size fits all" solution, they created Galleon, a generic provisioning tool. It provides the ability to easily create a server that provides the technologies you want, with a correct configuration, and with unneeded libraries not present on disk
, said Brian Stansberry, lead of the Wildfly project.
To get a clearer picture, suppose that a REST-based microservice application only utilizes the JAX-RS and logging features of Wildfly. Using Galleon, a custom Wildfly server can be built by running:
galleon.sh install wildfly:current --dir=micro-wildfly-server --layers=jaxrs,logging
It works by utilizing what Galleon calls layers. Layers are predefined sets of technology or configuration, such as EJB or JPA. Layers can then depend on other layers and Galleon automatically works out all of the dependencies, including transitive dependencies, to provision a slimmed-down and minimalist server.
Galleon has particular applicability when creating containers as it helps to reduce the overall size and footprint of the final image.
Although the Wildfly team recommends using the latest LTS release of Java to run Wildfly, they also strive to make sure it runs on the latest JVM. Stansberry said, We want developers who are trying to evaluate what the latest JVM means for their applications to be able to look to WildFly as their development platform.
At the time of Wildfly 16’s release, JDK12 was still in the release candidate phase but all testing with this version indicated that it’s expected to run well on JDK12.
The Wildfly release also brought a number of messaging and clustering improvements to the platform.
On the messaging side, Wildfly improved message-driven beans (MDBs) and memory usage of the embedded broker. Specifically, MDBs can now be controlled by multiple delivery groups where delivery is conditional on all delivery groups being active. And users can now configure the maximum amount of memory used by the embedded broker before it begins applying a broker full strategy such as dropping or rejecting messages.
On the clustering side, clusters behind mod_cluster have improved traffic handling and improved tooling to locate the primary provider of a highly available (HA) singleton deployment or service. More concretely, new Wildfly servers added to a cluster behind mod_cluster will now work with the load balancer to gradually ramp up traffic to the server rather than allowing all traffic at once. This helps reduce the chance of overloading the server with too much traffic.
Additionally, the CLI can now be used to connect to any member of the cluster and determine the primary location of a HA singleton deployment or service. Previously the CLI only displayed whether the service or deployment was deployed, not which node or instance was the primary.
To get more details or to learn more about Wildfly 16, be sure to checkout their documentation and guides.