Red Hat has released version 10.1 of their WildFly application server. Significant new features include:
- Full HTTP/2 support
- Automatic generation of TLS certificates
- Improved load balancing
- Support for clustering node discovery on Azure
- Numerous bug fixes
WildFly now offers full “out-of-the-box” HTTP/2 support. As described in the WildFly announcement:
Unique to WildFly, is that HTTP/2 now works without any special JVM flags (even on Java 8!), configuration changes, or keystore changes. You simply point your browser at port 8443 and WildFly will automatically generate a self-signed TLS cert for you, and negotiate HTTP/2 if your browser supports it (most do). When you are ready to deploy in production, you simply update the keystore with whatever cert you would like to present to your users.
Improved load balancing is accomplished through a new profile, called “load-balancer” in the default domain.xml file. Profiles in domain mode allow for centralized management of multiple nodes (physical or virtual). This allows for multiple instances of WildFly that can be configured to provide different services.
WildFly Swarm
As defined in the WildFly Swarm website:
WildFly Swarm offers an innovative approach to packaging and running Java EE applications by packaging them with just enough of the server runtime to "java -jar" your application.
WildFly Swarm is built upon the foundation of WildFly.
Chris Tozzi, Senior Editor of content, and a DevOps Analyst at Fixate IO, discussed the benefits of WildFly Swarm in a recent Red Hat blog:
Simply put, WildFly Swarm lets you take a JavaEE app and boil it down to only the essential parts necessary to run it as an uber-JAR file. The result is a leaner, meaner way to deploy Java apps.
In short, WildFly Swarm lets you fully embrace all the benefits of a microservices-oriented development and deployment workflow. You no longer have to take a monolithic approach to building and running JavaEE apps. Instead, you can compile and deploy just the parts you need, and leave out everything you don’t.
Jason Greene, Platform Architect for JBoss EAP at Red Hat (who previously spoke to InfoQ about WildFly 8) has now spoken to InfoQ about this latest release of WildFly:
InfoQ: What is your current role at Red Hat?
Greene: I am the Platform Architect for JBoss EAP, and also the community project lead for WildFly. Additionally, I represent Red Hat on the Java EE expert group, where we are working towards Java EE8.
InfoQ: Other than the full HHTP/2 support and automatic generation of TLS certificates, what else makes WildFly unique over other application servers such as GlassFish and JOnAS?
Greene: While a number of alternatives have their own strengths focused in a particular area, WildFly excels all around. It’s extremely light-weight and developer friendly, while at the same time optimal for runtime workloads. It has a full enterprise feature set, yet is 100% open source, with a truly open community. It meets the Java EE Full Profile certification, but can be fully customized and slimmed as required. It has a rich management model capable of multi-node management, as well simple single node management, if preferred. It is the defacto "have your cake and eat it too” application server.
InfoQ: What advice can you provide for developers and organizations on when to choose, WildFly, WildFly Swarm, or JBoss EAP when starting a project?
Greene: A key part of the Red Hat software model, is that we have two offerings: a community offering (WildFly) which focuses on delivering the latest technology and innovation as quickly as possible, and an enterprise subscription (JBoss EAP) that focuses on delivering releases with long maintenance cycles, strong compatibility, vendor certification, additional hardening, and of course, first-class support with guaranteed SLAs. JBoss EAP is itself derived from WildFly, with key features back ported based on demand, and as such the transition from WildFly to EAP is a breeze. Finally, while JBoss EAP is our commercial offering, it is also available for free for development use, so you can download it just by registering a JBoss.ORG account.
WildFly Swarm is an exciting new effort that brings Java EE to micro-services. It is based on the WildFly project/architecture, but adds a new deployment model that reconstitutes the application server around your application in a customized, right-sized jar file. It also includes special integrations for APIs useful to a service mesh, such as Netflix Ribbon. It also fully supports the MicroProfile, a recent standard created by the enterprise Java community for micro-services.
While the needs of a particular project may better suit one of these options, it’s hard to make a wrong choice, since they all share the same underlying, powerful, and flexible architecture.
InfoQ: In your opinion, how will the delay of JavaEE and Java 9 affect future development of WildFly, WildFly Swarm, or JBoss EAP?
Greene: WildFly and JBoss EAP both go beyond the EE standard and are continually evolving. When a spec delay occurs, we just focus on other interesting areas. That said, we do prefer the standards keep pace with the industry, so we were happy to team up with other major players in the development of the MicroProfile.
Roy van Rijn, Software Craftsman at JPoint, recently blogged with his thoughts on the future of Java EE:
Vendors like Red Hat (owner of WildFly) are already breaking up their Java EE implementation using frameworks like WildFly Swarm. Swarm allows you to package and run just the parts of the specification you’re using. This is, what I think, the real future of enterprise Java.
Resources
RedHat provides examples to get started using WildFly and WildFly Swarm:
