JBoss EAP vs. WildFly : What’s the difference?

I heard the following question a lot, what is the difference between JBoss EAP and Widfly? It is a very good question which deserves a detailed answer, that’s what I will try to do throw this article!

Introduction

This article will help you in understanding the difference between WildFly / JBoss AS / JBoss EAP which all refer to the Java Enterprise application server created by the JBoss Team.

Before going further in the differences, let’s understand the beginning of the story with Marc Fleury (born 1968 in Paris) who is the creator of JBoss AS which means Java Bean Open-Source Software Application Server. Fleury’s research interest focused on middleware, he started the JBoss project in 1999. JBoss Group, LLC was incorporated in 2001 in Atlanta, Georgia. JBoss became a corporation under the name JBoss, Inc. in 2004.

So, the generic term JBoss AS refers to the first name of the Community version Java application server.  

After selling his company to Red Hat, Fleury became Senior Vice President and General Manager of the JBoss Division until he left Red Hat on 9 February 2007.

Since 2006, Red Hat provides commercial support for the JBoss Application Server. Therefore, to disambiguate between the Community (JBoss AS) and Commercial (JBoss EAP) version the term “WildFly” has been coined for the Community version. This happened after the JBoss AS version 7, and the first WildFly version was 8, this is proof that WildFly is picking up from where JBoss AS left on.

Therefore, the following distinction applies:

    WildFly: The community version of the Application Server

    JBoss EAP: The supported version of the Application Server, EAP Stands for Enterprise Application Platform.

Just as every new release of JBoss EAP was once built from JBoss AS, today, every new JBoss EAP release is built from WildFly. In fact, a lot of new features that end up in JBoss EAP start their lives in WildFly, so you can imagine that there are more similarities than differences.

Releases

Developers can think of WildFly as an incubation ground for new JBoss features. WildFly employs a continuous delivery model, which means new WildFly releases happen more frequently than JBoss EAP releases. This gives WildFly users the chance to use new features or provide feedback on the latest builds before the code is integrated into a JBoss EAP release. In comparison, JBoss EAP releases occur much more infrequently.

Please note that to better meet customer expectations, micro-releases for JBoss EAP have been discontinued and replaced with updates delivered on a repeating schedule. Each new update contains several bug fixes for customer reported issues and potentially several security fixes.

Let’s first understand the terms that a JBoss EAP administrator shall know:

• Individual Patch:
  • An individual patch addresses a single issue and is not tested in combination with any other patches.
  • Individual patches are delivered to customers via support cases and then incorporated into the next possible cumulative patch update.
  • The application of multiple individual patches in a single environment may lead to unanticipated product configurations which can lead to unexpected behavior.
• Cumulative Patch:
  • A cumulative patch is a delivery mechanism by which customers can update their existing installations to the most recent patch level without the need for a new installation.
  • A cumulative patch consists of multiple bug and/or security fixes which are tested together.
  • Cumulative patches encompass prior cumulative patches as well, so only the last cumulative patch in a minor release family needs to be applied.
  • Application of a cumulative patch will automatically invalidate previously installed individual patches.
  • Cumulative patches will be made available via the Customer Portal approximately every 6 weeks.
• RPM:
  • RPM is a mature software delivery mechanism, which provides the structure and tools for managing software in Red Hat Enterprise Linux.
  • All cumulative patch updates will have corresponding RPM updates.
  • RPM updates will be made available via the appropriate minor version RPM channel.

Mapping WildFly versions with JBoss EAP versions

Firstly, it is not possible to map exactly a version of the Community version WildFly with the corresponding version of JBoss EAP. This is because they are maintained in separated branches. However, the following table shows which WildFly version is the baseline to build a JBoss EAP version.

Java Compatibility

In the following tables you can see the Java EE / Jakarta EE Compatibility Matrix for each version of:

• WildFly

• JBoss EAP

Please note that WildFly 27 has passed the Jakarta EE 10 TCK and its compatibility certification request has been approved by the Jakarta EE Spec Committee. So, since the version 27, WildFly is a Jakarta EE 10 Full/Core/Web platform compatible implementation. That is why we can expect that JBoss EAP 8 will be also compatible Java EE 10!

Support

JBoss Enterprise Application Platform is Red Hat’s supported application server. JBoss EAP is still an opensource project but if you want to use JBoss EAP in production with Red Hat’s support, then you need to activate a subscription.

If you have an active subscription with Red Hat for JBoss EAP, then you can access to:

• Binary download (specific version and patches): https://access.redhat.com/downloads
• Enterprise support from Red Hat

If not, so you are simply testing/developing applications, then you can have access to the Red Hat developer program (0S subscription), then you can access to:

• Binary download (specific version): https://developers.redhat.com/products/eap/download

As you might notice, there are two major differences:

• You can access the binary installation files but not to the patches available for that server release,
• You are on your own, as far as support is concerned.

WildFly application server is not supported as a product by Red Hat. On the other hand, you can count on the community to get help at various levels:

• Through the Forum currently hosted in a Google Group: https://groups.google.com/forum/#!forum/wildfly
• Using StackOverFlow, setting as item “wildfly”: https://stackoverflow.com/questions/tagged/wildfly

A question that often comes up, can I use WildFly in production?

Basically, there are no restrictions in using WildFly in production. On the other hand, if you are planning to do that, you are strongly advised to migrate to the latest version of WildFly, as old versions are not maintained by any community of developers.

We recommend being an active member of WildFly community if you want to deploy WildFly in an Enterprise context. So, you can report bugs or submitting Pull Requests on the WildFly Project, also be aware about the upcoming features.

Installation mode

The binaries of JBoss EAP and WildFly are available at the locations shared before.

JBoss EAP could be installed in three ways:

• ZIP Installation
  Download, move the ZIP file to the server and location where JBoss EAP should be installed, and extract the ZIP archive:
  unzip jboss-eap-7.x.x.zip
• JBoss EAP Installer
  Download, move the ZIP file to server where JBoss EAP should be installed, then execute the following command:
  • For graphical installer:
    java -jar jboss-eap-7.x.x-installer.jar
    You can use the automatic installation script XML file:
    java -jar jboss-eap-7.x.x-installer.jar auto.xml
  • For text-based installer:
    java -jar jboss-eap-7.x.x-installer.jar -console
• RPM Installation
  Installing JBoss EAP via RPM requires a subscription to both the Red Hat Enterprise Linux Server base software repository, as well as a specific JBoss EAP repository.

The following is the complete JBoss EAP Installation Guide: https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.4/html/installation_guide/index

WildFly could be installed in three ways:

• ZIP Installation
  Same way as for JBoss EAP, download, move, and extract the ZIP file.
• Bootable JAR
  Same as for JBoss EAP.
• Galleon Installation
  The Galleon maven plugin or Galleon CLI are used to install WildFly:
  galleon.sh install wildfly:current --dir=my-wildfly-server

The following is the complete WildFly Installation Guide: https://docs.wildfly.org/23/Getting_Started_Guide.html

Patch JBoss EAP

Let’s have an overview on patching, as it is only available for JBoss EAP.

Starting with JBoss EAP 6.2, a JBoss CLI command called patch has been added for the application of both individual and cumulative patches. The Management Console could also be used to apply or rollback a patch.

Applying a Patch:

Apply the patch using the following command from the management CLI, including the appropriate path to the patch file you already downloaded:

patch apply /path/to/downloaded-patch.zip

Restart the JBoss EAP server for the patch to take effect.

Rolling Back a Patch:

If the patch has any undesirable effects, rollback it using the Management Console or the CLI.

To rollback the patch using the management CLI , use the patch history command to find the ID of the patch that you want to roll back, then Roll back the patch :

patch rollback --patch-id=PATCH_ID --reset-configuration=TRUE

Caution: If reset-configuration set to true, the patch rollback process will also roll back the JBoss EAP server configuration files to their pre-patch state. Any changes that were made to the JBoss EAP server configuration files after the patch was applied will be lost!

If you are using a managed domain, don’t forget to add the –host=HOSTNAME to the command.

Restart the JBoss EAP server for the patch roll back to take effect.

Configuration mode

Both JBoss EAP and WildFly support two ways of configurations, below an overview of both modes:

• Standalone mode
  Standalone servers are ideal for running a single instance of EAP as a single server. In a standalone server, all settings appear in a single configuration file:
  JBOSS_HOME/standalone/configuration/standalone.xml
  
  Within this file, users can configure different subsystems that comprise the features of this server, such as logging, messaging, and managing datasources. A standalone server could only have one profile defined; the standard profile is the default. Three other profiles are available (Full, Ha, and Full-Ha):
  JBOSS_HOME/standalone/configuration/standalone-full.xml
JBOSS_HOME/standalone/configuration/standalone-ha.xml
JBOSS_HOME/standalone/configuration/standalone-full-ha.xml
  
  To start a standalone instance with full-ha profile:
  JBOSS_HOME/bin/standalone.sh --server-config=standalone-full-ha.xml

• Domain mode
  The domain mode differs from traditional Standalone mode and allows you to deploy and manage EAP instances in a multi-server topology.
  To understand EAP managed domains, you need to understand the following terms:
  • Domain controller
    A single process that acts as the central management control point for a domain. The Domain controller is also referred to as the master host controller.
  • Host controller
    A process running on a host machine that relays configuration information, runtime status, and management commands to EAP server instances on that machine. The host controller is also referred to as a slave.
  • Process controller
    A process running on a host machine that starts host controllers and server instances on that machine.
  • Server 
    An EAP server instance running in its own JVM process. It runs application code; that is, it acts as an application server.
    
    In the following figure, the light gray boxes represent machines. They could be either physical or virtual machines. Each machine corresponds to a host and runs a process controller (not shown in the figure) and a host controller. Each machine also runs two server instances, but there could be more or less of them.
    
    In a managed domain, one of the host controller instances is configured to act as the central management point, that is, to act as the domain controller.

Management tools

Both JBoss EAP and WildFly can be configured using the command-line management CLI, web-based management console, Java API, or HTTP API. Changes made using these management interfaces persist automatically and the XML configuration files are overwritten by the Management API. The management CLI and management console are the preferred methods. It is not recommended to edit the XML configuration files manually.

Below an overview of CLI and Management Console:

• Command Line Interface
  The CLI is a management tool for a managed domain or standalone server. It allows a user to connect to the domain controller or a standalone server and execute management operations available through the de-typed management model.
  
  To launch the CLI in Linux, run the following script file:
  JBOSS_HOME/bin/jboss-cli.sh -c --controller=vmjboss:9990
  
  It is even possible to execute commands directly:
  JBOSS_HOME/bin/jboss-cli.sh -c --controller=vmjboss:9990 --commands="deploy application.war,deployment-info --name=application.war"
  
  These commands allow to deploy an application and get the application information once deployed.
  
• Management Console
  The Management Console is a web-based administration tool. The Management Console is used to start and stop servers, deploy and undeploy applications, tune system settings, and make persistent modifications to the server configuration.
  
  The Management Console also can perform administrative tasks, with live notifications when any changes require the server instance to be restarted or reloaded.
  In a Managed Domain, server instances and server groups in the same domain can be centrally managed from the Management Console of the domain controller.
  
  The below figure shows the Configuration tab in JBoss EAP Management Console version 7.0.
  

Building MicroProfile applications using JBoss EAP and WildFly

A key difference between JBoss EAP and WildFly relates to the development of MicroProfile applications.

• In WildFly, MicroProfile API are available out of the box in the full server distribution. The configuration files named standalone-microprofile.xml and standalone-microprofile-ha.xml can be used to develop Jakarta EE applications in combination with the MicroProfile API.
• In JBoss EAP, MicroProfile API are included in the Eclipse MicroProfile Expansion Pack (JBoss EAP XP) which is available as a patch stream, when using JBoss EAP XP manager. Therefore, you need to install JBoss EAP XP on the top of JBoss EAP to have the supported MicroProfile API with EAP.

Conclusion

These two Java application servers have more in common than they differ. There are almost the same in terms of installation, configuration, and capacities.

The key difference for me is the support, using WildFly on production environment may be a risk depending on the Recovery Time Objective (RTO).