© The WildFly Authors.

1. Getting Started with WildFly 34

WildFly 34 is the latest release in a series of JBoss open-source application server offerings. WildFly 34 is an exceptionally fast, lightweight and powerful implementation of the Jakarta Enterprise Edition 10 specifications. WildFly’s modular architecture built on the JBoss Modules and JBoss Modular Service Container projects enables services on-demand when your application requires them. The table below lists the Jakarta technologies available in WildFly 34 server configuration profiles.

Jakarta EE Platform Technology Jakarta EE Full Platform Jakarta EE Web Profile WildFly 34 Full Configuration WildFly 34 Default Configuration

Jakarta Activation 2.1

X

 — 

X

X

Jakarta Annotations 2.1

X

X

X

X

Jakarta Authentication 3.0

X

X

X

X

Jakarta Authorization 2.1

X

 — 

X

 — 

Jakarta Batch 2.1

X

 — 

X

 — 

Jakarta Bean Validation 3.0

X

X

X

X

Jakarta Concurrency 3.0

X

X

X

X

Jakarta Connectors 2.1

X

 — 

X

X

Jakarta Contexts and Dependency Injection 4.0

X

X

X

X

Jakarta Debugging Support for Other Languages 2.0

X

X

X

X

Jakarta Dependency Injection 2.0

X

X

X

X

Jakarta Enterprise Beans 4.0

X

X(Lite)

X

X(Lite)

Jakarta Enterprise Web Services 2.0

Optional

 — 

X

X

Jakarta Expression Language 5.0

X

X

X

X

Jakarta Interceptors 2.1

X

X

X

X

Jakarta JSON Binding 3.0

X

X

X

X

Jakarta JSON Processing 2.1

X

X

X

X

Jakarta Mail 2.1

X

 — 

X

X

Jakarta Messaging 3.1

X

 — 

X

 — 

Jakarta MVC 2.1 (preview stability)

 — 

 — 

 — 

 — 

Jakarta Pages 3.1

X

X

X

X

Jakarta Persistence 3.1

X

X

X

X

Jakarta RESTful Web Services 3.1

X

X

X

X

Jakarta Security 3.0

X

X

X

X

Jakarta Faces 4.0

X

X

X

X

Jakarta Servlet 6.0

X

X

X

X

Jakarta SOAP with Attachments 3.0

Optional

 — 

X

X

Jakarta Standard Tag Library 3.0

X

X

X

X

Jakarta Transactions 2.0

X

X

X

X

Jakarta WebSocket 2.1

X

X

X

X

Jakarta XML Binding 4.0

Optional

X

X

X

Jakarta XML Web Services 4.0

Optional

 — 

X

X

WildFly Preview 34 is currently aiming at providing an early look at Jakarta EE 11, and therefore provides different versions of a number of the Jakarta specifications listed above. See EE 11 Support in WildFly Preview for details.

WildFly 34 also provides support for a number of MicroProfile technologies:

MicroProfile Technology WildFly 34 Default Configuration WildFly 34 MicroProfile Configuration

MicroProfile Config 3.1

X

X

MicroProfile Fault Tolerance 4.0

 — 

X

MicroProfile Health 4.0

 — 

X

MicroProfile JWT Authentication 2.1

X

X

MicroProfile LRA 2.0

 — 

 — 

MicroProfile OpenAPI 3.1

 — 

X

MicroProfile Reactive Messaging 3.0

 — 

 — 

MicroProfile Rest Client 3.0

X

X

MicroProfile Streams Operators 3.0

 — 

 — 

MicroProfile Telemetry 1.1

 — 

X

Missing ActiveMQ Artemis and Jakarta Messaging?

WildFly’s default configuration provides Jakarta EE Web Profile support and thus doesn’t include Jakarta Messaging (provided by ActiveMQ Artemis). As noted in the WildFly Configurations section, other configuration profiles do provide all features required by the Jakarta EE Full Platform. If you want to use messaging, make sure you start the server using an alternate configuration that provides the Jakarta EE Full Platform.

This document provides a quick overview on how to download and get started using WildFly 34 for your application development. For in-depth content on administrative features, refer to the WildFly 34 Admin Guide.

2. Requirements

  • Java SE 11 or later. We recommend that you use the latest available update of the current long-term support Java release.

3. Installation Options

There are a number of ways you can install WildFly, including unzipping our traditional download zip, provisioning a custom installation using Galleon, or building a bootable jar. There are also two variants of the server: the standard "WildFly" variant and the tech-preview "WildFly Preview" variant used to showcase things in the works for future release of standard WildFly.

The Installation Guide helps you identify the kind of WildFly installation that best fits your application’s deployment needs. In this guide we’ll focus on the common approach of installing the download zip of standard WildFly.

3.1. Download

WildFly 34 distributions can be obtained from:

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

  • wildfly-34.0.0.Final.zip

  • wildfly-34.0.0.Final.tar.gz

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

  • wildfly-preview-34.0.0.Final.zip

  • wildfly-preview-34.0.0.Final.tar.gz

3.2. Installation

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

4. WildFly - A Quick Tour

Now that you’ve downloaded WildFly 34, the next thing to discuss is the layout of the distribution and explore the server directory structure, key configuration files, log files, user deployments and so on. It’s worth familiarizing yourself with the layout so that you’ll be able to find your way around when it comes to deploying your own applications.

4.1. WildFly Directory Structure

DIRECTORY DESCRIPTION

appclient

Configuration files, deployment content, and writable areas used by the application client container run from this installation.

bin

Start up scripts, start up configuration files and various command line utilities like elytron-tool, add-user and Java diagnostic report available for Unix and Windows environments

bin/client

Contains a client jar for use by non-maven based clients.

docs/schema

XML schema definition files

docs/examples/configs

Example configuration files representing specific use cases

domain

Configuration files, deployment content, and writable areas used by the domain mode processes run from this installation.

modules

WildFly is based on a modular classloading architecture. The various modules used in the server are stored here.

standalone

Configuration files, deployment content, and writable areas used by the single standalone server run from this installation.

welcome-content

Default Welcome Page content

4.1.1. Standalone Directory Structure

In " standalone " mode each WildFly 34 server instance is an independent process (similar to previous JBoss AS versions; e.g., 3, 4, 5, or 6). The configuration files, deployment content and writable areas used by the single standalone server run from a WildFly installation are found in the following subdirectories under the top level "standalone" directory:

DIRECTORY DESCRIPTION

configuration

Configuration files for the standalone server that runs off of this installation. All configuration information for the running server is located here and is the single place for configuration modifications for the standalone server.

data

Persistent information written by the server to survive a restart of the server

deployments

End user deployment content can be placed in this directory for automatic detection and deployment of that content into the server’s runtime.NOTE: The server’s management API is recommended for installing deployment content. File system based deployment scanning capabilities remain for developer convenience.

lib/ext

Location for installed library jars referenced by applications using the Extension-List mechanism

log

standalone server log files

tmp

location for temporary files written by the server

tmp/auth

Special location used to exchange authentication tokens with local clients so they can confirm that they are local to the running AS process.

4.1.2. Domain Directory Structure

A key feature of WildFly 34 is the managing multiple servers from a single control point. A collection of multiple servers are referred to as a " domain ". Domains can span multiple physical (or virtual) machines with all WildFly instances on a given host under the control of a Host Controller process. The Host Controllers interact with the Domain Controller to control the lifecycle of the WildFly instances running on that host and to assist the Domain Controller in managing them. The configuration files, deployment content and writeable areas used by domain mode processes run from a WildFly installation are found in the following subdirectories under the top level "domain" directory:

DIRECTORY DESCRIPTION

configuration

Configuration files for the domain and for the Host Controller and any servers running off of this installation. All configuration information for the servers managed wtihin the domain is located here and is the single place for configuration information.

content

an internal working area for the Host Controller that controls this installation. This is where it internally stores deployment content. This directory is not meant to be manipulated by end users.Note that "domain" mode does not support deploying content based on scanning a file system.

lib/ext

Location for installed library jars referenced by applications using the Extension-List mechanism

log

Location where the Host Controller process writes its logs. The Process Controller, a small lightweight process that actually spawns the other Host Controller process and any Application Server processes also writes a log here.

servers

Writable area used by each Application Server instance that runs from this installation. Each Application Server instance will have its own subdirectory, created when the server is first started. In each server’s subdirectory there will be the following subdirectories:data — information written by the server that needs to survive a restart of the serverlog — the server’s log filestmp — location for temporary files written by the server

tmp

location for temporary files written by the server

tmp/auth

Special location used to exchange authentication tokens with local clients so they can confirm that they are local to the running AS process.

4.2. WildFly 34 Configurations

4.2.1. Standalone Server Configurations

  • standalone.xml (default)

    • Jakarta web profile certified configuration with the required technologies plus those noted in the table above.

  • standalone-ha.xml

    • Jakarta web profile certified configuration with high availability

  • standalone-full.xml

    • Jakarta Full Platform certified configuration including all the required technologies

  • standalone-full-ha.xml

    • Jakarta Full Platform certified configuration with high availability

  • standalone-microprofile.xml

    • A configuration oriented toward microservices, providing our MicroProfile platform implementations combined with Jakarta RESTful Web Services and technologies Jakarta RESTful Web Services applications commonly use to integrate with external services.

  • standalone-microprofile-ha.xml

    • A configuration oriented toward microservices, similar to standalone-microprofile.xml but with support for high availability web sessions and distributed Hibernate second level caching.

4.2.2. Domain Server Configurations

  • domain.xml

    • Jakarta full and web profiles available with or without high availability

Important to note is that the domain and standalone modes determine how the servers are managed not what capabilities they provide.

5. Starting WildFly 34

To start WildFly 34 using the default web profile configuration in " standalone" mode, change directory to $JBOSS_HOME/bin.

./standalone.sh

To start the default web profile configuration using domain management capabilities,

./domain.sh

5.1. Starting WildFly with an Alternate Configuration

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:

./standalone.sh --server-config=standalone-full-ha.xml

Similarly to start an alternate configuration in domain mode:

./domain.sh --domain-config=my-domain-configuration.xml

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

5.2. Test Your Installation

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

=========================================================================
 
  JBoss Bootstrap Environment
 
  JBOSS_HOME: /opt/wildfly-10.0.0.Final
 
  JAVA: java
 
  JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=com.yourkit,org.jboss.byteman -Djava.awt.headless=true
 
=========================================================================
 
11:46:11,161 INFO  [org.jboss.modules] (main) JBoss Modules version 1.5.1.Final
11:46:11,331 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
11:46:11,391 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly 10.0.0.Final (WildFly Core 2.0.10.Final) starting
<snip>
11:46:14,300 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly 10.0.0.Final (WildFly Core 2.0.10.Final) started in 1909ms - Started 267 of 553 services (371 services are lazy, passive or on-demand)

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:

wildfly.png

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 34 but can easily be replaced with your own if desired.

6. Managing your WildFly 34

WildFly 34 offers two administrative mechanisms for managing your running instance:

  • a web-based Administration Console

  • a command-line interface

The Admin Guide covers the details on managing your WildFly installation. Here we’ll just touch on some of the basics.

6.1. Authentication

By default WildFly 34 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: -

./add-user.sh
What type of user do you wish to add?
 a) Management User (mgmt-users.properties)
 b) Application User (application-users.properties)
(a):

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: -

Enter the details of the new user to add.
Realm (ManagementRealm) :
Username :
Password :
Re-enter Password :

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.

What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[  ]:

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:

Is this new user going to be used for one AS process to connect to another AS process?
e.g. for a secondary host controller connecting to the primary or for a Remoting connection for server to server Jakarta Enterprise Beans calls.
yes/no?

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

6.2. Administration Console

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:

port 9990 is the default port configured.
<management-interfaces>
    <http-interface http-authentication-factory="management-http-authentication">
        <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
        <socket-binding http="management-http"/>
    </http-interface>
</management-interfaces>

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.

6.3. Command-Line Interface

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

$JBOSS_HOME/bin/jboss-cli.sh --connect
Connected to standalone controller at localhost:9990

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.

6.4. Deploying an Application

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.

If you are running a WildFly managed domain, the deployment-scanner subsystem is not available so you will need to use the CLI or web console to deploy your application. For more, see the Admin Guide.

6.5. Modifying the Example DataSource

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:

  1. as a module

  2. as a deployment

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.

<subsystem xmlns="urn:jboss:domain:datasources:1.0">
    <datasources>
        <datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS">
            <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
            <driver>h2</driver>
            <pool>
                <min-pool-size>10</min-pool-size>
                <max-pool-size>20</max-pool-size>
                <prefill>true</prefill>
            </pool>
            <security>
                <user-name>sa</user-name>
                <password>sa</password>
            </security>
        </datasource>
        <xa-datasource jndi-name="java:jboss/datasources/ExampleXADS" pool-name="ExampleXADS">
           <driver>h2</driver>
           <xa-datasource-property name="URL">jdbc:h2:mem:test</xa-datasource-property>
           <xa-pool>
                <min-pool-size>10</min-pool-size>
                <max-pool-size>20</max-pool-size>
                <prefill>true</prefill>
           </xa-pool>
           <security>
                <user-name>sa</user-name>
                <password>sa</password>
           </security>
        </xa-datasource>
        <drivers>
            <driver name="h2" module="com.h2database.h2">
                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
            </driver>
        </drivers>
  </datasources>
</subsystem>

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

6.6. Configure Logging in WildFly

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:

/subsystem=logging/logger=org.jboss.as:add(level=DEBUG)

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.