Red Hat

WildFly 11 Final is now available!

WildFly 11 Final is now available for download! 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:

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:

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 WildFly.

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:


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:


New Load-Balancer Configs

In order to simplify the setup of WildFly 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).

Further Reading

In the run-up to the release, we have been blogging about WildFly 11’s features. These articles contain detailed information and useful tips on how take advantage of these capabilities, so be sure to take a look!

Table 1. Recent Articles
Author Title

Emmanuel Hugonnet

Using exploded deployments and CLI attachments

Farah Juma

How to secure EJBs with Elytron and invoke them from remote clients

Farah Juma

EJB invocations from remote servers

Farah Juma

How to use an Elytron SASL mechanism that supports channel binding

Claudio Miranda

Admin/Web Console Features & Enhancements

Darran Lofthouse

WildFly Elytron - Add Kerberos Authentication to Existing Web Application

Darran Lofthouse

Using WildFly Elytron with Undertow Standalone

Brian Stansberry

Management Model Referential Integrity and Suggestions

Jeff Mesnil

Messaging features in WildFly 11

Stuart Douglas

OpenSSL & HTTP/2

Ken Wills

Embedded Hostcontroller

Jira Release Notes

The full list of issues resolved is available here.

What’s Next

Now that WildFly 11 is out the door, we plan to move to a faster, more incremental release model, starting with WildFly 12. Expect to see more details here in the future, and as always, your contributions are welcome!

Running an Embedded WildFly Host Controller in the CLI

WildFly supports running a standalone server in Offline mode as an embedded server. An analogous capability has been added for domain mode in the form of running an offline host controller. This article discusses some of the details and possible applications of this feature.


For those not familiar with the existing embedded standalone server, see: Offline mode Running an Embedded WildFly 9 Server in the CLI · WildFly. One of the major use cases of this feature was to allow local administration of a WIldFly / JBoss EAP instance without requiring a socket based connection, or opening any local ports but still enabling configuration and administration operations. The embedded approach also allows for a fast boot that will allow multiple concurrent running instances to co-exist without configuring any additional socket offsets or interfaces to avoid port conflicts etc.

Using and the embed-host-controller command enables a fast and flexible means of configuring host controller instances and servers.

Embedded Host Controller

In a similar way to the standalone embed-server command, the embed-host-controller command is provided, to start an embedded host controller running in the CLI. This host controller is started in admin-only mode, and no servers are started. [See below for more details on admin-only restrictions].

Starting an embedded Host Controller:

$ ./bin/

You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] embed-host-controller --std-out=echo
11:07:46,723 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.6.0.Final
11:07:46,825 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.7.SP1
11:07:46,870 INFO  [] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 11.0.0 (WildFly Core 3.0.1.Final) starting
[ Note: some startup output omitted for brevity. ]
11:07:48,845 INFO  [] (Controller Boot Thread) WFLYSRV0025: WildFly Full 11.0.0 (WildFly Core 3.0.1.Final) (Host Controller) started in 2105ms - Started 56 of 61 services (18 services are lazy, passive or on-demand)

[domain@embedded /] ls -l
ATTRIBUTE                VALUE           TYPE
domain-organization      undefined       STRING
launch-type              EMBEDDED        STRING
local-host-name          master          STRING
management-major-version 5               INT
management-micro-version 0               INT
management-minor-version 0               INT
name                     Unnamed Domain  STRING
namespaces               []              OBJECT
process-type             Host Controller STRING
product-name             WildFly Full    STRING
product-version          11.0.0          STRING
release-codename         Kenny           STRING
release-version          3.0.1.Final     STRING
schema-locations         []              OBJECT

CHILD                     MIN-OCCURS MAX-OCCURS
core-service              n/a        n/a
deployment                n/a        n/a
deployment-overlay        n/a        n/a
extension                 n/a        n/a
host                      n/a        n/a
host-exclude              n/a        n/a
interface                 n/a        n/a
management-client-content n/a        n/a
path                      n/a        n/a
profile                   n/a        n/a
server-group              n/a        n/a
socket-binding-group      n/a        n/a
system-property           n/a        n/a

The non-modular client may also be used from the bin/client WildFly distribution:

$ java -jar bin/client/jboss-cli-client.jar
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] embed-host-controller --jboss-home=/wildfly-11.0.0
Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions.
[domain@embedded /] cd /host=master/server-config=server-one
[domain@embedded server-config=server-one] ls -l
ATTRIBUTE                            VALUE             TYPE
auto-start                           true              BOOLEAN
cpu-affinity                         undefined         STRING
group                                main-server-group STRING
name                                 server-one        STRING
priority                             undefined         INT
socket-binding-default-interface     undefined         STRING
socket-binding-group                 undefined         STRING
socket-binding-port-offset           0                 INT
status                               STOPPED           STRING
update-auto-start-with-server-status false             BOOLEAN

interface       n/a        n/a
jvm             n/a        n/a
path            n/a        n/a
ssl             n/a        n/a
system-property n/a        n/a
[domain@embedded server-config=server-one]

See Modular vs Non-Modular Classloading and JBOSS_HOME in the original embedded server news article for details.

Executing commands:

[domain@embedded /]  /host=master/interface=public:write-attribute(name=inet-address, value=
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined,
    "response-headers" => {"process-state" => "reload-required"}


[domain@embedded /] reload --host=master --admin-only=true
11:17:20,092 INFO  [] (Controller Boot Thread) WFLYSRV0025: WildFly Full 11.0.0 (WildFly Core 3.0.1.Final) (Host Controller) started in 279ms - Started 56 of 61 services (18 services are lazy, passive or on-demand)
[domain@embedded /]

Note that currently, the embedded host controller may only be started / reloaded in admin-only mode. In domain mode, servers are started and stopped via use of the process controller which is not currently supported as part of embedded mode.


[domain@embedded /] stop-embedded-host-controller
11:08:29,925 INFO  [] (MSC service thread 1-7) WFLYSRV0050: WildFly Full 11.0.0 (WildFly Core 3.0.1.Final) stopped in 13ms

Command usage:

The embed-host-controller command has several options that behave in the same way as the previously mentioned standalone embedded server, which will not be discussed again here. The relevant embed-host-controller parameters are:

-c                - Name of the domain configuration file to use
                     (default is "domain.xml")
                     (Same as --domain-config)

--domain-config   - Name of the domain configuration file to use
                     (default is "domain.xml")
                     (Same as -c)

--host-config     - Name of the host configuration file to use
                     (default is "host.xml")

As mentioned above, --jboss-home, --std-out and --timeout may also be provided and function in the same manner as the embed-server command. The configuration files mentioned above (domain.xml, host.xml) above should be located in the $JBOSS_HOME/domain/configuration directory (or under the location pointed to by the system property jboss.domain.config.dir.) [See Command Line Properties for additional details on those properties.]

For example, to start an embedded host controller with configuration files contained in the otherdomain/configuration directory:

[wildfly-11]$ ./bin/ -Djboss.domain.config.dir=/wildfly-11/otherdomain/configuration
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] embed-host-controller --std-out=echo
11:26:44,122 INFO  [] (Controller Boot Thread) WFLYSRV0025: WildFly Full 11.0.0 (WildFly Core 3.0.1.Final) (Host Controller) started in 1894ms - Started 56 of 61 services (18 services are lazy, passive or on-demand)
[domain@embedded /]

Configuration may then proceed and will be persisted to the otherdomain/configuration directory. This directory must already exist and contain base copies of the required configuration files (host.xml, domain.xml etc.).

Scripted configuration

The embedded host controller may be useful for configuration from a prepared file of scripted CLI commands. For example:

$ cat commands.cli
/server-group=main-server-group:write-attribute(name=socket-binding-port-offset, value=100)
/host=master/server-config=server-one:write-attribute(name=auto-start, value=false)
deploy --all-server-groups test.war

$ ./bin/ --file=commands.cli
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined

This approach may be used for a variety of setup and configuration tasks, for example setting up unit or integration tests quickly using the embedded host controller, then restarting in domain mode using may require less time than starting the host controller normally using, performing configuration and deployment etc, then restarting.

Other examples

Set server socket-binding-port-offset

In order to allow more than one running instance on the same host, a common configuration for testing (or any scenario needing to run a domain controller and a slave host controller (with servers) on the same host), a socket-binding-port-offset is commonly used. The slave host is configured to have a port offset so that the ports already in use by the domain controller’s servers do not conflict with those of the slave.

[domain@embedded /] /server-group=main-server-group:write-attribute(name=socket-binding-port-offset, value=100)
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined

Configure connection to remote domain controller

When configuring a slave host controller, configure the connection to the domain controller.

[domain@embedded /] /host=master:write-remote-domain-controller(host=remotedc.somedomain.tld, security-realm=ManagementRealm)
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined,
    "response-headers" => {"process-state" => "reload-required"}

System property

This can be useful as an initial configuration step before the host controller is started with

[domain@embedded /] /server-group=main-server-group/system-property=foo:add(value=bar)
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined

Future Direction

In the future we’d like to allow for starting the embedded host controller with some additional features, such as empty configurations in host and domain configuration files (similar to standalone embedded), and also re-examine the meaning and usage of --admin-only in the context of the embedded host controller.

OpenSSL support with WildFly

The upcoming WildFly 11 release includes support for OpenSSL. This provides two main advantages over JSSE:

  • Support for ALPN on all JDK’s

  • Significantly improved performance compared to JSSE

Setting up OpenSSL

In general for Linux based systems all that is required is to install a recent version of OpenSSL using your systems package manager. The OpenSSL support will search the library path, and use whatever version of OpenSSL it finds. The same applies to MacOS when OpenSSL has been installed using brew (the system default OpenSSL installation is too old).

For windows and for custom OpenSSL locations you need to specify the location via a system property, org.wildfly.openssl.path. If this is set then Wildfly will search for OpenSSL in the directory specified. If you have multiple versions of OpenSSL in the same directory and need to specify the precise file to use you can instead use org.wildfly.openssl.path.ssl and org.wildfly.openssl.path.crypto to specify the path to libssl and libcrypto respectively.

As Wildfly uses dynamic linking this should work with any OpenSSL version from 1.0.1 onwards (however for security reasons it is recommended to always use the most up to date 1.1.x or 1.0.x version that is available, as older versions may have unpatched vulnerabilities).

Setting up Wildfly with Security Realms

As Wildfly supports SSL out of the box with dynamically generated self signed certificates all that is required is to change the protocol in use. Doing this is as simple as running a single command in the CLI:

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

Other valid values are openssl.TLSv1.1 and openssl.TLSv1.2, which limit the minimum TLS version to 1.1 and 1.2 respectively.

Once this is done you can use OpenSSL by simply pointing your browser to https://localhost:8443. You should see the following message in the log that tells you that OpenSSL is in use:

09:01:04,150 INFO  [org.wildfly.openssl.SSL] (MSC service thread 1-6) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2l  25 May 2017

Setting up Wildfly with Elytron

As Elytron is not used by default there is a little bit more work involved in setting it up. Elytron does not support auto generation of SSL certificates, so for the sake of this example I am going to assume that the keystore is located at standalone/configuration/application.keystore (the same location that the auto generated keystore is placed, if you just want a self signed certificate for testing purposes you can simply connect to https://localhost:8443 with the default configuration and one will be generated for you).

In order to set up SSL using Elytron run the following commands (note that this is just to use JSSE, the OpenSSL config will come later).

/subsystem=elytron/key-store=server:add(path=application.keystore, relative-to=jboss.server.config.dir, credential-reference={clear-text=password}, type=jks)
/subsystem=elytron/key-manager=server:add(key-store=server, credential-reference={clear-text=password}, algorithm=SunX509)
/subsystem=elytron/server-ssl-context=server:add(key-manager=server, protocols=[TLSv1.2])
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value=server)

If you point your browser at https://localhost:8443 you should now have a working Elytron based SSL config. Once you have verified that this has worked we now need to change it to use OpenSSL. To do this we change the ordering of the providers in the elytron combined-providers, which means that OpenSSL will now take precedence:

/subsystem=elytron/aggregate-providers=combined-providers:list-add(index=0, name=providers, value=openssl)
/subsystem=elytron/aggregate-providers=combined-providers:list-remove(index=2, name=providers)

You should now have OpenSSL working with Elytron.

back to top