Red Hat

Using Git for configuration history

Until now the history of configuration in WildFly was using the folder + filename pattern. Now we have moved to a proper SCM integrating Git to manage history.

You can now take advantage of a full Git support for your configuration history:

  • every change in your configuration is now a commit.

  • you can use branches to develop in parallel.

  • you can create tags for stable points in your configuration.

  • pull configuration from a remote repository.

  • push your configuration history to a remote repository.

  • use the git-bisect tool at your disposal when things go wrong.

Now if we execute a management operation that modifies the model, for example adding a new system property using the CLI:

[standalone@localhost:9990 /] /system-property=test:add(value="test123")
{"outcome" => "success"}

What happens is:

  • The change is applied to the configuration file.

  • The configuration file is added to a new commit.

The notion of configuration has been updated with the Git support. It covers more than 'just' the standalone.xml history but also the content files (aka managed deployments).

Thus even your deployments are in history, which makes sense in a way since those deployments appear in the configuration file.

Starting with a local Git repository

To start using Git you don’t have to create the repository, WildFly can do that for you. Just start your server with the following command line:

$ __WILDFLY_HOME__/bin/ --git-repo=local --git-branch=my_branch

If a --git-branch parameter is added then the repository will be checked out from the supplied branch. Please note that the branch will not be automatically created and must already exist in the repository. By default, if no parameter is specified, the branch master will be used. If a --git-branch parameter is added then the repository will be checked out from the supplied branch. Please note that the branch will not be automatically created and must already exist in the repository. By default, if no parameter is specified, the branch master will be used.

Starting with a remote Git Repository

To start WildFly with a configuration from a remote Git repository is simple too, just use the following command line:

$ __WILDFLY_HOME__/bin/ --git-repo= --git-branch=master

Be careful with this as the first step is to delete the configuration files to avoid conflicts when pulling for the first time.

Note that you can use remote aliases if you have added them to your .gitconfig.


In addition to the commits taken by the server as described above, you can manually take snapshots which will be stored as tags in the Git repository.

The ability to take a snapshot has been enhanced to allow you to add a comment to it. This comment will be used when creating the Git tag.

This is how you can take a snapshot from the JBoss CLI tool:

[standalone@localhost:9990 /] :take-snapshot(name="snapshot", comment="1st snapshot")
    "outcome" => "success",
    "result" => "1st snapshot"

You can also use the CLI to list all the snapshots:

[standalone@localhost:9990 /] :list-snapshots
    "outcome" => "success",
    "result" => {
        "directory" => "",
        "names" => [
            "snapshot : 1st snapshot",
            "snapshot2 : 2nd snapshot",

To delete a particular snapshot:

[standalone@localhost:9990 /] :delete-snapshot(name="snapshot2")
{"outcome" => "success"}

Note that this is a real Git repository, thus using the git client of your choice you can list those tags, or browse the history.


You may 'publish' your changes on a remote repository (provided you have write access to it) so you can share them. For example, if you want to publish on GitHub, you need to create a token and allow for full control of the repository. Then use that token in an Elytron configuration file like this:

<?xml version="1.0" encoding="UTF-8"?>
    <authentication-client xmlns="urn:elytron:1.1">
            <rule use-configuration="test-login">
            <configuration name="test-login">
                <sasl-mechanism-selector selector="BASIC" />
                <set-user-name name="$GITHUB_USERNAME" />
                    <clear-password password="$GITHUB_TOKEN" />
                <set-mechanism-realm name="testRealm" />

Then, to publish your changes:

[standalone@localhost:9990 /] :publish-configuration(location="origin")
{"outcome" => "success"}


For the official documentation regarding Git history : Official Documentation.

What’s New in WildFly Management Console

WildFly 13 comes with a management console (HAL) which has been rewritten from scratch. HAL still uses a similar technical stack (GWT) and user experience, but now fully adopts PatternFly.

More important we enhanced the existing features and added support for many new subsystems and attributes. The following sections show some highlights of the latest version. For more details about the new features see the release notes for HAL 3.0.0.Final.


The column based navigation (finder) has been greatly improved. You can now use the cursor keys for navigation inside and across columns. To open an application view press ↵ (enter), to go back press ⌫ (backspace). Items in one column are now ordered alphabetically by default. You can pin frequently used items to stay at the top. Most columns offer a filter which can be used to quickly find the items you’re looking for. Finally the previews have been enriched and provide detailed documentation or the main attributes of the selected item. If appropriate the previews contain action links for the most common tasks.

Figure 1. Finder


Applications provide a new breadcrumb at the top to quickly switch between items of the same kind. More complex applications can include a vertical navigation. Finally most applications can be easily opened in an external window and provide an expert mode which uses the generic model browser.

Figure 2. Applications


Many new features have been added to the deployment section:

  • Use drag and drop to deploy artifacts

  • Content browser with preview for text and images

  • Create exploded deployments

  • CRUD support for exploded deployments:

    • Add empty files

    • Upload content

    • Modify content

    • Remove content

  • Download complete deployments or deployment content

Figure 3. Deployments

Deployment Model
Figure 4. Deployment Model

Content Browser
Figure 5. Content Browser


The topology view has been reintroduced to the management console. It was removed in the last versions due to performance issues with large domains. But thanks to new management operations, we were able to add this useful tool again.

Figure 6. Topology


The lifecycle operations for hosts, server groups and servers have been improved. New operations are available for hosts and disconnected hosts are now shown in the finder columns. For servers you can specify custom URLs which is extremely useful when running WildFly inside a docker container.

Figure 7. Runtime


The existing screens have been improved and many new subsystems have been added to the monitoring section. Some of the new and enhanced subsystems are:

  • Batch

  • EJB

  • IO

  • JAX-RS

  • Messaging

  • Web (Undertow)

Monitor Server
Figure 8. Monitor Server

EJB Subsystem
Figure 9. EJB Subsystem

JAX-RS Resources
Figure 10. JAX-RS Resources

Undertow Listener Statistics
Figure 11. Undertow Listener Statistics

Get Involved

If you want to learn more about HAL, head over to The new website contains both end user and technical documentation. Read about HAL’s architecture, building blocks and how you can build, run and debug the console. HAL is an open source project and we love to receive contributions from our community — you!

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