“Make jar, not war”
In the era of virtual servers and various cloud services, it has become common that a web server hosts only one web application. The overhead of having a separate execution environment for each web app, for both server room and maintenance people, has become so small that it often really makes sense. Applications, and especially their servers, are easier to maintain and less dependent on each other.
Having a separate application server in this kind of setup has become an overhead for the maintenance. The Spring Boot project has ignited a strong new trend in the Java web app scene, where the server is an integrated part of the deployment artifact. Applications are started with the good old public static void main(String[] args) method and java -jar myapp.jar command, which can considerably simplify both deployment and development (launching a main method is still simpler than using IDEs server integrations). “Make jar, not war”, like Josh Long from Pivotal tends to market Spring Boot.
Another advantage of this kind of Java web app packaging is that the deployment artifact may also become smaller (jar file vs. server + war file), as one can leave out features of the “application server” that are not used by your application.
Goodies for Java EE folks
The executable jar approach for Java web apps is by no means new, but the success of Spring Boot has been noticed by folks in the Java EE “camp”(*). There have been lots of instructions lately on how you can package your Java EE based web apps as executable jar files. For example Tomitribe recently wrote a really nice summary of various ways of how TomEE can be packaged together with your web application to create an “überjar” that you can call “microservice”. Payara Micro is an another approach that just eats your existing war file as a parameter and deploys it to the root context of a trimmed down Payara (a commercially supported GlassFish derivative) instance.
WildFly Swarm is a really interesting start from RedHat. It doesn’t only give you the easy maintenance with executable jar files, but, like Spring Boot, provides you a set of modular building blocks that you can pick into your “custom server”. If you, for example, don’t use JPA in your application, Hibernate won’t be included in your jar file. With this modularity, I see it as a first real “competitor” for Spring Boot.
How does it work with Vaadin?
Although Swarm is still more like a research project in alpha state, I wanted to try how it works with Vaadin. And it does, perfectly. Core Vaadin requires just a Servlet container, so you can get started just with the wildfly-swarm-undertow module, typical Vaadin dependencies and a VaadinServlet. But most users probably also want to use the CDI that comes with the wildfly-swarm-weld module and Vaadin CDI. With this setup the only thing you’ll need is a UI class with @CDIUI(“”) annotation and your first Wildfly Swarm powered Vaadin app is up and running.
The easiest way to get started is just to clone the examples project which contains an example setup for a Vaadin app with a UI that is wired to a simple CDI based service. It also requires the latest 1.0.0.Alpha4 release or a development build of Swarm itself, which you can build locally simply with mvn install -DskipTests=true.
Check out the Wildfly Swarm examples with a Vaadin project
(*) I really hate the classification of Java developers into Spring and Java EE tribes, and especially the constant “battles” between them, but there, I just had to do that myself. I love both Spring and Java EE :-)