WildFly Swarm - Basic Setup

Original post was in 2016, migrating to new blog

So I came across WildFly probably a month or two ago, bookmarked as something to come back to. While reading up more on it recently I stumbled upon WildFly Swarm, which seems to be like Spring Boot, Dropwizard and other uberjar/fatjar micro-service deployment solutions.

Definitely cool stuff! I love the idea of containers and just dropping down a self-encapsulated build of an API and being able to quickly rollback if needed. Front with nginx and what could be simpler?

I thought I would share some learnings and maven config stuff as a "get up and running in 10 minutes" sort of blog post.

Maven POM

First up, create your pom and add some properties.


Second, we need to add our dependencies block which includes the WildFly Swarm deps for JAX-RS and CDI (via Weld). I've also included Project Lombok because it's amazing, and joda-time was on some other article I came across.

    <!-- JAX-RS -->

    <!-- JAX-RS/CDI -->

    <!-- Project Lombok, it's awesome -->

    <!-- EJB API -->

    <!-- CDI API -->

    <!-- Common Annotations API (JSR-250) -->


Third, add our build section. A change from Alpha1 is that there is no longer an execution of "create", in case you read older articles/tutorials.





That concludes the pom configuration and at this point you should be able to do a mvn clean package and get a success.

Beans, beans, beans

You'll need to create a src/main/webapp/WEB-INF directory and then create a beans.xml file.

<?xml version="1.0" encoding="UTF-8"?>  
<beans xmlns="http://java.sun.com/xml/ns/javaee"  

JAX-RS Application

To active JAX-RS, you will need to create a class which extends Application and is annotated with @ApplicationPath.

package com.example.application;

import javax.ws.rs.ApplicationPath;

public class Application extends javax.ws.rs.core.Application {  
  // let the container scan for @Path resources

API Model

At this point we will create our WebAPI model. This blog post is designed using a 2-layer approach for simplicity, showing a controller, model and a service (controller and service share the same model).

I was introduced to the Project Lombok library from the guys at Tomitribe. It is a fantastic little library which generates no-args constructor, all-args consturctor, getters (accessors), setters (mutators), hashcode and equals, internal builders and a few other treats. It helped reduce so much boilerplate code, I was blown away so I use it everywhere I can.

package com.example.webapi.models;

import java.io.Serializable;

import javax.xml.bind.annotation.XmlAccessOrder;  
import javax.xml.bind.annotation.XmlAccessType;  
import javax.xml.bind.annotation.XmlAccessorOrder;  
import javax.xml.bind.annotation.XmlAccessorType;  
import javax.xml.bind.annotation.XmlRootElement;

import lombok.AllArgsConstructor;  
import lombok.Data;  
import lombok.NoArgsConstructor;

@XmlRootElement(name = "test")
public class Test implements Serializable {  
  private int id;
  private String name;

In case you are wondering, lombok will create methods for getId(), setId(), getName() and setName().

JAX-RS Resource

There are multiple semantics/names for this class, you might see it as Resource, Service or Controller (I use Controller).

This is the class that is annotated with the JAX-RS annotations and handles the API requests. Just some fair warning, there is no error checking/handling here. So if you pass a 2 or greater as the ID this will croak.

package com.example.webapi.controllers;

import com.example.webapi.models.Test;  
import com.example.webapi.providers.TestProvider;

import java.util.List;

import javax.ejb.Lock;  
import javax.ejb.Singleton;  
import javax.inject.Inject;  
import javax.ws.rs.Consumes;  
import javax.ws.rs.DefaultValue;  
import javax.ws.rs.GET;  
import javax.ws.rs.Path;  
import javax.ws.rs.PathParam;  
import javax.ws.rs.Produces;  
import javax.ws.rs.QueryParam;  
import javax.ws.rs.core.Response;

import lombok.extern.java.Log;

import static javax.ejb.LockType.READ;  
import static javax.ws.rs.core.MediaType.APPLICATION_JSON;  
import static javax.ws.rs.core.MediaType.APPLICATION_XML;

public class TestController {  
    private TestProvider testProvider;

    @Path("{id: \\d+}")
    public Response getCollection(
        final int id
    ) {
        log.info("id:" + id);
        final List<Test> models = testProvider.findAll();
        return Response.ok(models.get(id)).build();

Test Provider (Service Pattern)

The last class needed for this very basic example is the TestProvider, which is following the Service Pattern, which would provide all of your business logic.

package com.example.webapi.providers;

import com.example.webapi.models.Test;

import java.util.ArrayList;  
import java.util.List;

import javax.ejb.Singleton;  
import javax.ejb.Lock;  
import static javax.ejb.LockType.READ;

public class TestProvider {  
    public List<Test> findAll() {
        return new ArrayList<Test>() {{
            add(new Test(1, "emp01"));
            add(new Test(2, "emp02"));

Making It Go

You should now be able to fire off maven and run this thing. Execution can happen two ways, via the maven wildfly-swarm:run target, or packaging then running via java -jar.

mvn clean package wildfly-swarm:run  

Or build then run

mvn clean package  
java -jar target/yourpackage-swarm.jar  

Once this loads you can try to hit your endpoint by going to http://localhost:8080/tests/0 and http://localhost:8080/tests/1.

This concludes a very basic WildFly Swarm tutorial.