Red Hat

New WildFly Project Lead

I am very excited to announce that Brian Stansberry (@bestansberry) will be taking on the role of WildFly project lead. Brian has been a major contributor to the project for almost 15 years now. During this time, he led a number of critical and complex subsystems including Clustering, Management, and most recently the cross-cutting cloud integration work. He is also one of our most active reviewers, and has helped many contributors navigate deep WildFly internals. Congratulations Brian!

It’s been a great journey, so I want to think each and every one of you for your contributions and support over the years. Our work as a community has frequently pushed the envelope, and led to WildFly being one of the most innovative and popular application servers available. While I will be moving on from this role, I won’t be too far way, still participating but tackling a new challenge (I’ll have more to say about that in the future).

With Brian at the helm, and all the great folks contributing to the project, I know WildFly has a bright future. I look forward to seeing the next chapter.

Turn the page.

-Jason

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