Wildfly Swarm Hands on

Hi there, I have been playing little with Wildfly Swarm in the last couple of weeks, in this small post I’m going to explain what is and how we can use it.

What is it?

It is a side project of Wildfly ‘the java container for enterprise applications’, it puts the functionality you need in order to run your app in one single big file, easy to run and move around; copying the purpose from the home page “ helps you create self-contained Java microservices based upon the normal WildFly application-server” this tell us what is the main goal of this: use it as a microservice self-container application that can be scalated quickly using other container technology like Docker.

Configuration and Execution

The first thing is what kind of application you are building, if is a simple WAR file, you only need a swarm maven plug in, this plug in will take the needed dependencies available in your pom and create a big jar with the all it needs and your war inside.

Now, here is an important part, you need to inclue as many “Fractions” or subsystems as your application requires, you only need EJB? add the ejb dependency, CDI-weld? weld dependency, both? add both dependencies. See here the list of available fractions.

This is a big improvement in what you need is what you get; in swarm terminology the Fraction term is used as an equivalent as “jboss subsystems”, if you add a fraction it will come with default configuration ready to be used, if you want to modify more granular way you need to do it with the Java API.

Plug-in maven code:

Supose you have a simple war that expose a JAX-RS rest and returns a string with some values using weld for retrieval of data, what do you need?

  • Add jax-rs weld swarm dependency to your pom
  • Maven plug in

Here is how it should look like:

Now, how can we run it?

Before anything we need to build using mvn package command in order to tell swarm to bundle all the needed artifacts in one big fat jar in the target directory, the name of the jar will be ${yourFinalArtifactName}-swarm.jar.

Now we can run it with:

java -jar target/myprojectartifactname-swarm.jar

You see the output is like a normal jboss (because it is) all bundled, first the container will start and then is going to deploy your application.

By default it uses the 8080 port for HTTP without any context path so, the addres would look like this:


You can configure this settings passing some parameters as system properties or in the maven plug-in configuration. See details here.

If we need to add more manual configuration like datasources, resources, etc we can declare a Main class in our code (our app need to be a packaged as jar), this class needs to handle the lifecylcle of the Wildfly that is basically create the container, start it and add a deployment archive.

This archive could be of different types JAXRSArchive, JARArchive, etc also you can customize yours to your needs, this archive have some specific functionality like accepting web resources, add dependencies, etc. an archive is like the unit of your application is the way the container will deploy it, so be consistent.

Example of main class:

Example code with main class github

Final thoughts

  • Needs java 8.
  • Still in alpha (I use alpha5 for my examples).
  • I see a lot of potential here.
  • Need more documentation (Site is in progress), a lot of topics are not very clear yet but still improving each time I check the site.
  • Resource clean up is handled by the container as usual, but need to put special attention to this details in your portable apps.