A little while passed, many great things have happened 🙂

Back to Java EE world, when talking about cloud, containers, docker we should consider Wildfly Swarm. This JBoss’ child is a modularization of Java EE way beyond standard Java EE profiles (web, enterprise etc.). Main features of Swarm are:

  • Capability to construct application as a fat jar
  • Application’s fat jar will contain only required Java EE specifications (with implementation part of course) and framworks (e.g. Logstash)
  • Capability to add necessary dependencies based on structure of build automation tool descriptor (maven, gradle)
  • Capability to construct customized deployments (via Shrinkwrap)

Some of these features make Wildfly Swarm a little similar to Spring Boot, of course there are differences as configuration and deployment of Java EE application is different that that of Spring application. Let’s consider configuration – in Spring you can use java configuration or xml (if you like), every configuration is similar when this is considered. In Java EE there are different types and formats of configuration. EJBs, Serlvets mostly don’t need XML nowadays, but Java EE Batch – here you are stuck with XML. When using Wildfly Swarm there is a possibility to do some additional configuration that will augment Java EE configuration, but I would not bet that API of Swarm or Shrinkwrap will not change.

Maybe Spring Boot  can do more automatic configuration compared to Wildfly Swarm. This lack of belief is dictated by the way Java EE and Spring are configured. If we consider CDI we are not forced to add any configuration (starting from Java EE 7 even the beans.xml descriptor is not required). Looking at the JPA we can add datasources (Swarm specific part) and define persistence units (Java EE part) . So we can configure the application and how it is deployed, Spring Boot’s flexibility comes with Spring not the other way around in my opinion.

Enough of theoretical considerations. Let’s code. Spring Boot has excellent start.spring.io – Wildfly Swarm has Wildfly Swarm Project Generator. Name is maybe not so catchy as Spring’s but Swarm’s web app does basically the same thing and it is really smart to use it and not do the basic configuration your self. For demo app we need just the JAX-RS with CDI dependency. After downloading application’s zip we need to move it to where we want to and import to IDE. Below is pom file that I enhanced with Swarm’s plugin configuration, there rest is generated:

Important parts:

  • We import Wildfly swarm BOM to ensure matching versions are used. This is similar to Spring IO Platform BOM
  • We use WAR packaging – more on this below
  • We can configure debug port and we do configure bind address

Packaging set in maven impacts your application packaging and not the fat jar packaging. With Wildfly Swarm we always get packaged application and Wildfly Swarm generated fat jar. If we would use jar packaging then we would need to configure custom deployment using Shrinkwrap like in this example. Despite what is stated in Wildfly Swarm docs I could not run demo application using jar packaging. So AFAIK if you use jar packaging you are forced to write you own main method that deploys you app.

What we did so far is we created application that deploys JAX-RS with CDI and other required dependencies and only these. No EJBs, no JMS, no JSP. Great ! But if you peek into WAR’s lib there are a some libraries that could be excluded like Jackson JAXB module. Probably dependency meta data should be stated more precisely in order to exlude some of these. But some, like websockets lib, could be excluded. Java API for Websockets is separate specification and could be specified as a separate Widlfly Swarm dependency.

Passing on to Java Code, we need to create JAX-RS application class:

And then JAX-RS service:

We have only one way to execute Asycnhronous processing in JAX-RS, and this way is to use AsyncResponse that can be injected using @Suspended qualifier. AsyncResponse allows us to resume processing when response is ready, just like Servlet 3.x asynchronous API. Optionally we can specify timeout and timeout handler that will be executed when processing times out.

Example code contains also synchronous version of method. Possible upgrades include use of managed thread pools in Swarm instead of creating our own thread pool.

I had some trouble with VirtualBox VM with Docker so the app is not tested with Docker yet. I will do it in a few days. Code is available on GitHub, I will update it in a few days. In order to run application wildfly-swarm:run goal needs to be executed after project is build. I tried using wildfly-swarm:start goal but Wildfly was killed right after build was completed. Dockerized Wildfly example is available on Marcus Eisele blog.

Another way is to execute swarm-demo-swarm.jar from target directory, just execute:

java -jar swarm-demo-swarm.jar

Once Wildfly is up and running service can be accessed under http://localhost:8080/swarm/task-service/process-task?task-name=YOUR_TASK_NAME&task-param=parameter

To be continued… 🙂