Red Hat

WildFly 16 is released!

WildFly 16 Final is now available for download!

Provisioning WildFly with Galleon

As we continue with our quarterly delivery model, a major focus over the next few quarters will be on making WildFly as easy and productive as possible to use on the cloud, particularly on Kubernetes and OpenShift.

An important requirement for the cloud is to be able to reduce the footprint of your server to what you need to run your application, eliminating unneeded runtime memory overhead, cutting down image size and reducing the possibility for security vulnerabilities. So, I’m very excited to announce Tech Preview support for use of the Galleon provisioning tool to allow you to easily provision a slimmed down server tailored toward REST applications. By easily, I mean a simple command that provisions a server that provides the technologies you want, with a correct configuration, and with unneeded libraries not present on disk. Being able to do this is an important piece of foundational technology that we’ll be building upon over the course of 2019, particularly with tooling and best practices aimed at taking advantage of Galleon when creating cloud images.

Galleon provisioning isn’t just useful in cloud; users running on bare metal or virtualized environments can get the same benefits. Easy server slimming has been a goal for as long as I’ve been involved with JBoss AS!

To install the latest final version of WildFly into the directory my-wildfly-server call:

galleon.sh install wildfly:current --dir=my-wildfly-server

That’s not so interesting as the result is equivalent to unzipping the standard download zip.

WildFly still provides the usual zip / tar.gz. Using Galleon is not required to use WildFly.

The real power comes when using the Galleon layers that WildFly provides to limit your installation to just the technologies you need. For example, if all you want is jaxrs and cdi:

galleon.sh install wildfly:current --dir=my-wildfly-server --layers=cdi,jaxrs

The result is an installation that doesn’t include unnecessary modules, has a correct configuration and has less than a third of the disk footprint of the standard WildFly distribution. And you don’t have to worry about knowing and specifying technologies required by the ones you know you want (e.g. the servlet support that jaxrs needs). Galleon handles that for you.

If you’re ok with a slightly bigger footprint in order to have common WildFly Core management functionality, add the core-server and core-tools layers:

galleon.sh install wildfly:current --dir=my-wildfly-server --layers=cdi,jaxrs,core-server,core-tools

WildFly 16 provides a rich set of layers oriented toward letting optimize your server for running HTTP applications. For further details, see the WildFly Admin Guide and the Galleon documentation.

Please give Galleon provisioning a try and give us feedback! We’d love to hear about your use cases and how Galleon can be improved to meet them. We’ll be doing more articles and blog posts explaining how to take advantage of this technology.

JDK 12

While the GA version of JDK 12 has not been released yet (it is in the Release Candidate phase), we are pleased to report that WildFly 16 should run well on JDK 12 once it is GA. I’d like to especially thank Richard Opalka and Matej Novotny for their efforts in making this happen.

Our goal with WildFly is to have our releases run well for most use cases on the most recent GA JDK version available on the WildFly final release date. If practical we’ll try and run well on release candidates for upcoming JDK versions as well, which we’ve achieved with WildFly 16. By run well, I mean our main testsuite runs with no more than a few failures in areas not expected to be commonly used. (In the JDK 12 case we have no failures.) 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. It may not always be possible to attain this goal, but it’s one we take seriously.

While we do want to run well on the most recent JDK, our recommendation is that you run WildFly on the most recent long-term support release, i.e. on JDK 11 for WildFly 16. We do considerably more testing on the LTS JDKs.

WildFly 16 also is heavily tested and runs well on Java 8. We plan to continue to support Java 8 at least through WildFly 18.

Please note that WildFly runs on Java 11 and 12 in classpath mode.

Messaging Improvements

  • MDBs can be configured to belong to multiple delivery groups, with delivery only enabled only when all the delivery groups are active.

  • Users can use standard Java EE 8 resource definitions (annotations or xml) to define JMS resources that connect to a remote Artemis-based broker (including AMQ-7 instances).

  • Users can configure the maximum amount of memory that the embedded messaging broker can use to store messages for its addresses before they are considered "full" and their address-full-policy starts to apply (e.g. to drop messages, block producers, etc.)

Clustering Improvements

  • When WildFly servers behind a mod_cluster load balancer start they will instruct the load balancer to gracefully ramp up their load over the first minute or so of operation, instead of having the balancer send the maximum possible amount of traffic, possibly overwhelming the server.

  • Users running a cluster with HA Singleton deployments or services can connect with the CLI to any cluster member and determine which node is the primary provider of a given deployment or service.

Other Notable Items

  • You can use the CLI to list which modules are visible to a deployment. This is helpful in analyzing classloading issues.

  • In a WildFly managed domain, you can suspend and resume all of the servers managed by a particular Host Controller. Previously suspending or resuming multiple servers was limited to all servers in the domain or those in a particular server group.

  • When using Elytron, HTTP Basic authentication mechanism can be configured to only operate in 'silent mode', only sending a challenge if the request contained an authorization header.

Jira Release Notes

The full list of issues resolved is available here. Issues resolved in the WildFly Core 8 release included with WildFly 16 are available here.

WildFly 15 is released!

WildFly 15 Final is now available for download!

This is our fourth release following our quarterly delivery model. The major objective of this year’s release plan was to deliver EE8 functionality in incremental chunks over the first three quarters, and then to ensure WildFly ran well on the latest long term support version of Java. Accordingly, in this fourth release our focus was less on new features and more on polishing our support for JDK 11.

JDK 11 Support

The modularization of the JVM that began with Java 9 has a significant impact on a complex server like WildFly, particularly in the areas of classloading and reflection, both of which are extensively used in any application server. Since the early days of Java 9 development we’ve been working to ensure that not only the WildFly code itself, but also the scores of libraries we integrate, would all run well on the later generation JVMs. Specifically we wanted to be sure we ran well on the first long term supported Java version under the new Java SE release cadence, Java 11. We’re proud to say we’ve achieved that goal in our first quarterly release since Java 11 itself went GA.

WildFly 15 also is heavily tested and runs well on Java 8. We also do testing with non-LTS releases like Java 9 and 10, and aim to run reasonably well for most use cases on those, but the primary aim of that kind of testing is to identify problems early enough to resolve them for the upcoming LTS release.

Please note that WildFly runs on Java 11 in classpath mode.

Server Observability

Continuing the effort from WildFly 14 to improve the ability of tools to observe the behavior of WildFly in a container environment, in WildFly 15 we added a new subsystem that brings tech-preview support for MicroProfile Metrics. Application authors can declare their own application-scoped metrics, and those as well as base metrics will be available in Prometheus or JSON format over a new /metrics context on the HTTP management interface.

SNI Support for HTTPS Listeners

WildFly 15 supports server side SNI on its HTTPS listeners. This allows a WildFly instance listening on a single socket but with multiple virtual hosts associated with that listener to provide a different server certificate depending on what SNI name the client requests.

Default SSL Context

Setting a simple attribute on the Elytron subsystem ensures that as the server is started a JVM-wide default SSLContext is registered for use by any libraries within the application server that support use of the default context.

JASPIC Integration with Elytron

The Elytron subsystem now provides support for the Servlet Container Profile of the JSR-196 Java Authentication SPI for Containers spec.

Jira Release Notes

The full list of issues resolved is available here. Issues resolved in the WildFly Core 7 release included with WildFly 15 are available here.

WildFly 14 is released!

WildFly 14 Final is now available for download!

EE8 Certified!!

I am happy to announce that the WildFly 14 release is Java EE8 Certified! Since WildFly is now certified, the default EE7 mode and EE8 preview option have been dropped. The server now only provides EE8 APIs in all run modes. Since Java EE8 is backwards compatible with EE7, applications developed against EE7 (and earlier) will still run on WildFly 14.

This is our third release following our new quarterly delivery model. A major theme of this plan, was to deliver EE8 functionality in fully completed incremental chunks, as opposed to waiting for everything to finish in a big bang release. This goal has now been completed, and we greatly appreciate the feedback and support from the community during this process. We plan to continue this model going forward.

An overview of the new and updated standards in Java EE8 are as follows:

Name From Version From JSR To Version To JSR

Java Servlet

3.1

JSR-340

4.0

JSR-369

Contexts and Dependency Injection for Java

1.2

JSR-346

2.0

JSR-365

Bean Validation

1.1

JSR-349

2.0

JSR-380

JavaServer Faces

2.2

JSR-344

2.3

JSR-372

JavaMail

1.5

JSR-919

1.6

JSR-919

Java API for RESTFul Web Services

2.0

JSR-339

2.1

JSR-370

Java API for JSON Processing

1.0

JSR-353

1.1

JSR-374

Java API for JSON Binding

-

-

1.0

JSR-367

Common Annotations for the Java Platform

1.2

JSR-250

1.3

JSR-250

Java EE Security

-

-

1.0

JSR-375

Java Persistence

2.1

JSR-338

2.2

JSR-338

MicroProfile Capabilities

Another major improvement in WildFly 14 is the inclusion of a number of important MicroProfile standards that are useful for running in container environments.

These include:

  • MP Config

  • MP OpenTracing

  • MP Health

High Performance Connection Pool

Also new in WildFly 14, is a new high performance direct connection pool backed by the Agroal project. Since this is a new pooling implementation, it must be explicitly enabled to take advantage of it. By default, the existing JCA based implementation (IronJacamar) is still used; however, in a future release, Agroal may become the new default. For more information, please see the WildFly 14 documentation.

Mod-Cluster Multiplicity

Mod cluster support within WildFly previously only supported a single web server listener and server configuration on a WildFly instance. Mod-cluster has now been enhanced to support multiple web server configurations by adding the ability to declare and reference multiple mod-cluster configurations within its subsystem.

Jira Release Notes

The full list of issues resolved is available here.

back to top