Getting Started Guide

WildFly 31 distributions can be obtained from:

wildfly.org/downloads

Standard WildFly 31 provides a single distribution available in zip or tar file formats.

WildFly Preview 31 also provides a single distribution available in zip or tar file formats.

Simply extract your chosen download to the directory of your choice. You can install WildFly 31 on any operating system that supports the zip or tar formats. Refer to the Release Notes for additional information related to the release.

If you choose to start your server with one of the other provided configurations, they can be accessed by passing the --server-config argument with the server-config file to be used.

To use the Full Platform with clustering capabilities, use the following syntax from $JBOSS_HOME/bin:

Similarly to start an alternate configuration in domain mode:

Alternatively, you can create your own selecting the additional subsystems you want to add, remove, or modify.

After executing one of the above commands, you should see output similar to what’s shown below.

As with previous WildFly releases, you can point your browser to http://localhost:8080 (if using the default configured http port) which brings you to the Welcome Screen:

From here you can access links to the WildFly community documentation set, stay up-to-date on the latest project information, have a discussion in the user forum and access the enhanced web-based Administration Console. Or, if you uncover a defect while using WildFly, report an issue to inform us (attached patches will be reviewed). This landing page is recommended for convenient access to information about WildFly 31 but can easily be replaced with your own if desired.

By default WildFly 31 is distributed with security enabled for the management interfaces. This means that before you connect using the administration console or remotely using the CLI you will need to add a new user. This can be achieved simply by using the add-user.sh script in the bin folder.

After starting the script you will be guided through the process to add a new user: -

In this case a new user is being added for the purpose of managing the servers so select option a.

You will then be prompted to enter the details of the new user being added: -

It is important to leave the name of the realm as 'ManagementRealm' as this needs to match the name used in the server’s configuration. For the remaining fields enter the new username, password and password confirmation.

Users can be associated with arbitrary groups of your choosing, so you will be prompted if you would like to do this.

Groups can be useful for simplified administration of things like access permissions, but for simply getting started, leaving this blank is fine.

Provided there are no errors in the values entered you will then be asked to confirm that you want to add the user, the user will be written to the properties files used for authentication and a confirmation message will be displayed.

The modified time of the properties files are inspected at the time of authentication and the files reloaded if they have changed. For this reason you do not need to re-start the server after adding a new user.

Finally, you will be asked whether the account you’ve added is going to be to used to identify one WildFly process to another, typically in a WildFly managed domain:

The answer for this should be no; the account you are adding here is for use by a human administrator.

To access the web-based Administration Console, simply follow the link from the Welcome Screen. To directly access the Management Console, point your browser at:

http://localhost:9990/console

If you modify the management-http socket binding in your running configuration: adjust the above command accordingly. If such modifications are made, then the link from the Welcome Screen will also be inaccessible.

If you prefer to manage your server from the command line (or batching), the jboss-cli.sh script provides the same capabilities available via the web-based UI. This script is accessed from $JBOSS_HOME/bin directory; e.g.,

Notice if no host or port information provided, it will default to localhost:9990.

When running locally to the WildFly process the CLI will silently authenticate against the server by exchanging tokens on the file system, the purpose of this exchange is to verify that the client does have access to the local file system. If the CLI is connecting to a remote WildFly installation then you will be prompted to enter the username and password of a user already added to the realm.

Once connected you can add, modify, remove resources and deploy or undeploy applications. For a complete list of commands and command syntax, type help once connected.

WildFly provides a number of ways you can deploy your application into the server. These are covered in detail in the Admin Guide.

If you are running a standalone WildFly server, the simplest way to deploy your application is to copy the application archive (war/ear/jar) into the $JBOSS_HOME/standalone/deployments directory in the server installation. The server’s deployment-scanner subsystem will detect the new file and deploy it.

As with previous JBoss application server releases, a default data source, ExampleDS , is configured using the embedded H2 database for developer convenience. There are two ways to define datasource configurations:

In the provided configurations, H2 is configured as a module. The module is located in the $JBOSS_HOME/modules/com/h2database/h2 directory. The H2 datasource configuration is shown below.

The datasource subsystem is provided by the IronJacamar project. For a detailed description of the available configuration properties, please consult the project documentation.

WildFly logging can be configured with the web console or the command line interface. You can get more detail on the Logging Configuration page.

Turn on debugging for a specific category with the CLI:

In the example above the org.jboss.as log category was configured. Use a different value for the logger key to configure a different log category.

By default, the server.log is configured to include all levels in its log output. In the above example we changed the console to also display debug messages.