In the previous step, we used the Swarm maven plugin to build the Uberjars. The plugin added the required fractions to enable your application. In some cases however that’s not possible, i.e. for API’s beyond Java EE or when you need to configure the fraction explicitly. In these cases you would need to provide a custom Main() to configure and bootstrap Swarm.

To explain the the fraction concept and it’s usage within Main(), we replace the current service registration code with the Swarm Topology fraction.

step 3.png
Figure 1. Uberjar Packaging

Concepts

  • Container, Config-API

  • Explicit fraction dependencies

  • Introduction to Shrinkwrap and it’s utility methods

Tasks

  • Add the maven dependencies for fractions that your application requires to each service module (jaxrs-jaxb, jaxrs-jsonp, jpa, jaxrs-cdi, ejb)

  • Add the maven dependency for the Swarm topology (topology-consul)

  • Change the maven packaging from war to jar

  • Provide a custom Main() to configure the Swarm runtime

  • Within Main() explicitly register the consul fraction and make sure it is configured to point to http://<CONSUL_IP>:8500.

  • Deploy your application code using Shrinkwrap

  • Advertise your service using the Swarm topology layer (topology-consul) (Allows for removal of the custom service registration code in the services module)

Outcome

  • You can still start the services as before (java -jar)

  • Each service you start will be appear in Consul as before

  • The user interface that remained on WildFly still works as expected

Alternative activities

  • Add and configure logging fraction, i.e. to enable level DEBUG