How to version applications running on WildFly

This short tutorial will show you how to emulate an application versioning on JBoss EAP / WildFly with some simple management steps.

Versioning is the practice of assigning unique identifiers to software releases and updates. This is important for a number of reasons, including:

Tracking changes: Version numbers allow developers to keep track of the different versions of their software and the changes that were made between them. This is useful for debugging, testing, and maintaining the software.
Collaboration: Version numbers can help teams of developers coordinate their work and ensure that everyone is working on the same version of the software.
Distribution: Version numbers are used to identify and distribute software releases to users and customers. This makes it easier for users to know which version of the software they have installed and whether they need to update to a newer version.

In this article, we will discuss about versioning an artifact, such as a Web application (war) or an Enterprise Archive (.ear). There are different strategies for versioning WildFly applications. In general we can discuss application versioning in WildFly Domain mode and in Standalone Mode.

Versioning Applications in Domain Mode

When running WildFly in Domain Mode, you have the built-in concept of a Server Group. A Server Group is a set of WildFly Servers that are sharing a common configuration.

This is a natural match to keep different versions of an application. In fact, you can keep distinct versions of your application for every Server Group. For example, the Dev-Server-Group can host a Beta version of the application while the Prod-Server-Group can host the latest stable version of your artifact.

To learn more about WildFly in Domain mode check this article: http://How to configure WildFly in Domain mode

Versioning applications in Standalone Mode

When you are running in Standalone mode, if you deploy one application artifact, you will be automatically replacing the existing artifact, if any. In the second part of this article we will show how two artifacts for the same application can coexist in Standalone mode.

Let’s see a basic example. You have an application packaged as demowebapp-1.0.war with the following jboss-web.xml file that defines the context root:

<jboss-web>
  <context-root>/demowebapp</context-root>
</jboss-web>

Now we will deploy the application using WildFly Web Console so reach localhost:9990 and click on Deployments

jboss wildfly versioning tutorial

Pickup the application to be deployed as shown by the following picture and flag it as enabled:

jboss wildfly versioning tutorial

Now the twist: The Application Name is an unique identifier of the deployment. However the Runtime Name is the name by which the deployment should be known within a server’s runtime. This would typically be the same as ‘name’, but in some cases users may wish to have two deployments with the same ‘runtime-name’ both available in the deployment content repository, in which case the deployments would need to have distinct ‘name’ values but would have the same ‘runtime-name’.

As you can see, we have used demowebapp.war as runtime name. Now let’s deploy another version of the application, say demowebapp-2.0.war:

jboss wildfly versioning tutorial

As you can see, the runtime name is the same and the application is disabled otherwise there will be two applications with the same runtime name at the same time.