Red Hat

WildFly 11 CR1 is now available!

WildFly 11 CR1 is now available for download!

Since the Beta, 66 issues have been resolved. You can find the full list below. Provided that no major issues are found, we hope to release the final very soon.

The highlights of WildFly 11 are as follows:

Elytron - New Security Infrastructure

The biggest change in WildFly 11 is unification on a new common security framework across the full application server. Previously we had two separate security infrastructures (picketbox and security-realms), each covering separate use cases, and largely operating independent of the other. In addition to unification, Elytron brings a number of advanced capabilities such as privilege propagation across multiple service invocations, identity switching, pre-request TLS verification, and rich security policies. Finally it improves the overall extensibility of the system allowing for tight integration with SSO / IDP systems such as KeyCloak.

While WildFly 11 introduces a new security infrastructure, the existing security-domain and security-realm configurations and APIs are all present and internally mapped to Elytron. To further ease the impact of this change, WildFly 11’s default configurations still use the legacy security-domains and security-realms. A subsequent release will convert the default configurations over to the new configuration model.

For more information see the Elytron documentation: https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security

Simplified EJB / Naming Proxies

JNDI and EJB invocation have both been simplified and enhanced in WildFly 11. There is a new naming client library, WildFly Naming Client that allows you to easily configure access to WildFly with minimal properties and configuration. EJBs (and other resources) can be accessed in a dynamic discovery mode, or alternatively, in a new point to point mode that locks all EJB proxies to a specified address. This replaces the previous scoped context feature with more intuitive semantics that are ideal for ad-hoc behavior. Additionally, with the new Elytron authentication infrastructure, the user identity can now be changed in between requests. Finally, older clients from past WildFly releases can still be used with WildFly 11.

See the following for more information on the new WildFly Naming client:
https://github.com/wildfly/wildfly-naming-client

Request oriented EJB/JNDI over HTTP

Since WildFly 8, all protocols (with the exception of IIOP) can utilize HTTP Upgrade to communicate over a reduced set of ports on the server (one for management, and one for applications). However, since HTTP Upgrade converts the connection to the native protocol used, any HTTP load-balancers acting as an intermediary can only balance on initial connection establishment. To allow for balancing at the individual invocation level, a new “pure” HTTP protocol was added. Clients which utilize http:// URLs as opposed to remoting+http:// will obtain this new behavior. Since this protocol utilizes standard HTTP behavior, it can be efficiently balanced by any load-balancer, not just the one built into EAP.

WildFly OpenSSL & HTTP/2

WildFly 11 now provides a JSSE provider that can offload TLS handling from the JVM’s internal implementation to an OpenSSL library on your system, typically improving TLS performance. If the version discovered and/or specified is 1.0.2 or greater, then WildFly will utilize OpenSSL’s ALPN support to provide HTTP/2 support. HTTP/2 support will be disabled on versions less than 1.0.2.

Note that HTTP/2 is also supported without OpenSSL, out of the box, on Java 8 (on VMs derived from OpenJDK) and Java 9 (using the new standard ALPN API).

You can enable OpenSSL in the default configurations with the following CLI command:

/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol,value=openssl.TLS)

If your openssl library is not installed in a standard location, you will need to additionally set the org.wildfly.openssl.path system property to point to the location of the library:

-Dorg.wildfly.openssl.path=/path/to/dir/with/openssl/lib

New Load-Balancer Configs

In order to simplify the setup of EAP as an HTTP load-balancer, there is an additional standalone-load-balancer.xml configuration in the distribution, which is an instance slimmed to just running the load balancing services. Additionally the stock domain.xml also includes this as a profile configuration that can be referenced by server groups.

Graceful Shutdown/Startup Improvements

Distributed transactions are now handled by the graceful shutdown mechanism. Existing transactions will allow local operations to continue, but any new in-flowed transaction will be rejected. Additionally there is a new EJB parameter that allows for additional remote calls to occur against an established/active remote transaction. Finally you can now start the server directly in suspended mode, for staging changes. This is now part of the default start sequence where the server enters suspend first, and then resumes after all services have launched, so new requests aren’t accepted during the brief window of the server starting.

Web Console Improvements

A number of Web Console improvements are included in WildFly 11, including the ability to see recent configuration changes, to manage active JMS transactions, manage active batch jobs, manage Undertow filters, and test data-sources during creation.

Management and Configuration Improvements

WildFly 11 now supports remote managed exploded deployments, which allows remote management clients the ability to update content within the deployment, such as html and jsp files without requiring a full redeployment. Additionally there is a new management operation that can be used to read individual files in any deployment. In addition to these new capabilities, errors in the XML now lead to pretty printed easier to understand error messages,

Also notable is that CLI tab completion can now tab complete attribute reference values that have capabilities present, such as references to socket bindings. Finally, there is a new SPI for server extensions, that can be used to register a process state listener, and react to server life-cycle changes (such as the server stopping).

Jira Release Notes

The full list of issues resolved is available here.

WildFly 11 Beta1 is now available!

WildFly 11 is now feature complete and the beta is now available for download!

This release includes a significant amount of change, with 459 issues completed since the Alpha, and includes a number of major changes, including architectural changes around a new richer security layer.

Since WildFly 11 is feature complete, and appears stable in our local testing, we aim to move to CR quickly.

The highlights of this release are as follows:

Elytron - New Security Infrastructure

The biggest change in WildFly 11 is unification on a new common security framework across the full application server. Previously we had two separate security infrastructures (picketbox and security-realms), each covering separate use cases, and largely operating independent of the other. In addition to unification, Elytron brings a number of advanced capabilities such as privilege propagation across multiple service invocations, identity switching, pre-request TLS verification, and rich security policies. Finally it improves the overall extensibility of the system allowing for tight integration with SSO / IDP systems such as KeyCloak.

While WildFly 11 introduces a new security infrastructure, the existing security-domain and security-realm configurations and APIs are all present and internally mapped to Elytron. To further ease the impact of this change, WildFly 11’s default configurations still use the legacy security-domains and security-realms. A subsequent release will convert the default configurations over to the new configuration model.

For more information see the Elytron documentation: https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security

Simplified EJB / Naming Proxies

JNDI and EJB invocation have both been simplified and enhanced in WildFly 11. There is a new naming client library, WildFly Naming Client that allows you to easily configure access to WildFly with minimal properties and configuration. EJBs (and other resources) can be accessed in a dynamic discovery mode, or alternatively, in a new point to point mode that locks all EJB proxies to a specified address. This replaces the previous scoped context feature with more intuitive semantics that are ideal for ad-hoc behavior. Additionally, with the new Elytron authentication infrastructure, the user identity can now be changed in between requests. Finally, older clients from past WildFly releases can still be used with WildFly 11.

See the following for more information on the new WildFly Naming client:
https://github.com/wildfly/wildfly-naming-client

Request oriented EJB/JNDI over HTTP

Since WildFly 8, all protocols (with the exception of IIOP) can utilize HTTP Upgrade to communicate over a reduced set of ports on the server (one for management, and one for applications). However, since HTTP Upgrade converts the connection to the native protocol used, any HTTP load-balancers acting as an intermediary can only balance on initial connection establishment. To allow for balancing at the individual invocation level, a new “pure” HTTP protocol was added. Clients which utilize http:// URLs as opposed to remoting+http:// will obtain this new behavior. Since this protocol utilizes standard HTTP behavior, it can be efficiently balanced by any load-balancer, not just the one built into EAP.

WildFly OpenSSL & HTTP/2

WildFly 11 now provides a JSSE provider that can offload TLS handling from the JVM’s internal implementation to an OpenSSL library on your system, typically improving TLS performance. If the version discovered and/or specified is 1.0.2 or greater, then WildFly will utilize OpenSSL’s ALPN support to provide HTTP/2 support. HTTP/2 support will be disabled on versions less than 1.0.2.

Note that HTTP/2 is also supported without OpenSSL, out of the box, on Java 8 (on VMs derived from OpenJDK) and Java 9 (using the new standard ALPN API).

You can enable OpenSSL in the default configurations with the following CLI command:

/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol,value=openssl.TLS)

If your openssl library is not installed in a standard location, you will need to additionally set the org.wildfly.openssl.path system property to point to the location of the library:

-Dorg.wildfly.openssl.path=/path/to/dir/with/openssl/lib

New Load-Balancer Configs

In order to simplify the setup of EAP as an HTTP load-balancer, there is an additional standalone-load-balancer.xml configuration in the distribution, which is an instance slimmed to just running the load balancing services. Additionally the stock domain.xml also includes this as a profile configuration that can be referenced by server groups.

Graceful Shutdown/Startup Improvements

Distributed transactions are now handled by the graceful shutdown mechanism. Existing transactions will allow local operations to continue, but any new in-flowed transaction will be rejected. Additionally there is a new EJB parameter that allows for additional remote calls to occur against an established/active remote transaction. Finally you can now start the server directly in suspended mode, for staging changes. This is now part of the default start sequence where the server enters suspend first, and then resumes after all services have launched, so new requests aren’t accepted during the brief window of the server starting.

Web Console Improvements

A number of Web Console improvements are included in WildFly 11, including the ability to see recent configuration changes, to manage active JMS transactions, manage active batch jobs, manage Undertow filters, and test data-sources during creation.

Management and Configuration Improvements

WildFly 11 now supports remote managed exploded deployments, which allows remote management clients the ability to update content within the deployment, such as html and jsp files without requiring a full redeployment. Additionally there is a new management operation that can be used to read individual files in any deployment. In addition to these new capabilities, errors in the XML now lead to pretty printed easier to understand error messages,

Also notable is that CLI tab completion can now tab complete attribute reference values that have capabilities present, such as references to socket bindings. Finally, there is a new SPI for server extensions, that can be used to register a process state listener, and react to server life-cycle changes (such as the server stopping).

Jira Release Notes

The full list of issues resolved is available here.

Announcing public CI

We are proud to announce our public CI system, which is running integration tests for WildFly, WildFly Core, Undertow, and many other related projects. This system ensures that we do not merge anything that is broken and that our master is always stable.

CI also helps us with testing pull requests by:

  • Making sure the code works on most common target platforms, currently Linux and Windows.

  • Integration testing components as part of the full WildFly test suite. This is most often used when testing WildFly Core, where we test core itself as well as changes to core integrated on top of WildFly. This ensures that the latest core always works with the latest WildFly master.

  • Running additional test suites such as mixed-domain tests, which are a bit harder to set up and run locally.

  • Running complex integration tests that span across multiple projects, such as Elytron integration work that is landing in WildFly 11.

It is also utilized to test WildFly against various platforms and JDK combinations, such as testing the IBM JDK on Linux and Windows, testing Solaris SPARC, as well as regularly testing early builds of JDK 9. CI also produces nightly builds of WildFly and WildFly core, which you can follow on our forums.

We are using TeamCity as our CI with a few of our own customizations, including the following:

  • A bit-modified, unofficial TeamCity.GitHub plugin that allows us to post failed tests and other details of the failure to the pull request.

  • A pull-player, which we use as our trigger for pull requests. It provides us with a whitelisting of pull request authors for which CI tests are auto-triggered to prevent denial-of-service attacks. It also provides an option to retrigger CI testing by adding the comment “retest this please” to the pull request.

The system is powered by three servers running an ESXi hypervisor with everything else virtualized.

The front entry point is running Nginx with configured HTTP that is using an SSL certificate provided by Let’s Encrypt.

The infrastructure is managed by Ansible with a set of our playbooks.

We would like to thank JetBrains, which kindly donated the open source license for TeamCity.

back to top