David Salter's Blog

... real developer's use subtitles

WildFly Swarm Project Generator

A few days ago, the WldFly Swarm team announced the release of the WildFly Swarm Project Generator.

WildFly Swarm Project Generator

The project generator allows you to select basic project properties (Maven Group ID and Artifact ID) and a list of dependencies for the project before creating a Maven project that can be downloaded and used from within your favorite IDE.

The list of dependencies is what makes this generator most useful to me. If you know the name of the dependency to add, or even a few letters from it, you can enter that in the dependencies field and the generator will automatically show the matching dependencies. For example, entering “rs” shows all the JAX-RS related dependencies.

WildFly Swarm Project Generator Dependencies

Once you’ve configured the name and dependencies for the project, selecting the “Generate Project” button downloads a zipped Maven project that’s ready for use and which can be run via maven by executing

1
mvn wildfly-swarm:run

The WildFly Swarm Generator is an excellent tool that reduces the barrier to developing with WildFly Swarm. If you’re a Swarm user, I’d recommend trying this out.

Deploying WildFly Swarm Applications To Heroku

WildFly Swarm applications can be deployed to Heroku, simply by adding a few files to the deployment. In this post, I’ll show the changes that are needed to be made to a WildFly Swarm application and how to then deploy the application to Heroku. I’ll show how to deploy my Fruits example WildFly Swarm application to Heroku. The source for this application can be cloned from GitHub at https://github.com/doobrie/swarm-rs

Creating a Heroku Application

Assuming that you’ve got the Heroku Toolbelt installed, creating a Heroku application is a matter of opening a command prompt/terminal in the root of a WildFly Swarm project (for this example, a Maven project), and executing the heroku create command.

1
2
3
$>heroku create
Creating app... done, stack is cedar-14
https://mighty-temple-xxxxx.herokuapp.com/ | https://git.heroku.com/mighty-temple-xxxxx.git

This creates a Heroku application, adding a git remote, heroku, ready for deploying your application.

Defining the Java Runtime

Heroku can automatically determine that your application is Java based, but needs to be told which version of Java to run. To define this, create a file called system.properties in the root of the project containing a single line indicating the version of Java required.

1
java.runtime.version=1.8

How To Execute The Application

Heroku uses a Procfile to determine how your application should be exeuted. This file should also be located in the root of your project. To run a web application, we need to tell Heroku to run a Web Dyno. We also need to tell it what command to run and what port to run on.

In Heroku, the port that applications must listen on is defined by the $PORT environment variable. A default WildFly Swarm application runs on port 8080, but this can be changed by adding the swarm.http.port environment variable. To execute a WildFly Swarm application, the Procfile should look something like

1
web:    java -Dswarm.http.port=$PORT -jar target/swarm-rs-1.0-SNAPSHOT-swarm.jar

Since we’re running a WildFly Swarm “fat” Jar, there are no additional class path entries required - all that is needed is the name of the Jar file containing the application, swarm-rs-1.0-SNAPSHOT-swarm.jar in this example.

Deploying The Application

That’s all that is required to get going with Heroku and WildFly Swarm. You can see that we’ve made no changes to the application itself other than adding a system.properties file to determine which Java runtime to use, and a Procfile to define how to start the application.

To deploy the application on Heroku, ensure these files are added and committed to the local Git repository and then push the changes to Heroku.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
$>git push heroku master

remote: [INFO] ------------------------------------------------------------------------
remote: [INFO] BUILD SUCCESS
remote: [INFO] ------------------------------------------------------------------------
remote: [INFO] Total time: 01:14 min
remote: [INFO] Finished at: 2016-02-07T21:49:57+00:00
remote: [INFO] Final Memory: 36M/389M
remote: [INFO] ------------------------------------------------------------------------
remote: -----> Discovering process types
remote: Procfile declares types -> web
remote:
remote: -----> Compressing...
remote: Done: 96.9M
remote: -----> Launching...
remote: Released v4
remote: https://mighty-temple-xxxxx.herokuapp.com/ deployed to Heroku
remote:
remote: Verifying deploy.... done.
To https://git.heroku.com/mighty-temple-xxxxx.git
* [new branch] master -> master

To verify that the application works, browse to the /api/fruit Url of the application. The Url of the application is displayed on the console after pushing to Heroku.

Conclusion

I’ve given an overview of how to deploy WildFly Swarm applications to Heroku. Hopefully you’ll agree that this is a straightfoward process that allows you to be quickly up and running on Heroku.

WildFly Swarm Maven Changes

Last week, a new version, 1.0.0.Alpha6 of WildFly Swarm was released. One of the main features of this release, from a development point of view, is the simplified handling of dependencies within a project’s pom.xml file.

All of the artifactId values for WildFly Swarm dependencies have been simplified from wildfly-swarm-artifactName to simply artifactName

Recently, I showed how to create a simple JAX-RS application using WildFly Swarm. With the previous version of WildFly Swarm, 1.0.0.Alpha5, the JAX-RS Swarm dependency was defined as:

1
2
3
4
5
<dependency>
<groupId>org.wildfly.swarm</groupId>
<artifactId>wildfly-swarm-jaxrs</artifactId>
<version>${swarm.version}</version>
</dependency>

Now, with version 1.0.0.Alpha6 of WildFly Swarm, the dependency looks like:

1
2
3
4
5
<dependency>
<groupId>org.wildfly.swarm</groupId>
<artifactId>jaxrs</artifactId>
<version>${swarm.version}</version>
</dependency>

Its a relatively small change, but it makes the pom.xml file more compact and readable.

I’ve updated my sample JAX-RS application on GitHub to support this latest version of WildFly Swarm.

NetBeans Darcula Theme

A new Darcula theme based upon the Darcula Look and Feel for IntelliJ has been released as a plugin for NetBeans.

This new plugin can be installed via the NetBeans Tools | Plugins option so there is no need to manually download the plugin to install it.

NetBeans Darcula Look and Feel

After installing the plugin, NetBeans needs to be restarted. Probably the first thing you notice after installation is that the editor window still retains the existing NetBeans colour scheme. The can be changed to a dark look and feel, for example, by using the Norway Today profile. After specifying this profile, you can customize the colours used within the editor window exactly how you like them, whilst retaining a full dark look and feel.

I really like this plugin. There are still some issues with it, for example the --fontsize NetBeans parameter doesn’t work with it, however that doesn’t detract from the use of the plugin which I now enable on all my NetBeans installations.

WildFly Swarm - Deploying Java EE Applications As Standalone Jars

WildFly Swarm provides an easy solution for deploying Java EE applications as a standalone Jar file. This makes it very easy to deploy applications, particularly REST or web services. Swarm is very similar to Spring Boot in that respect, in that it enables web (.War) applications to be developed quickly and then deployed as standalone applications without the need to deploy an application server.

The WildFly Swarm documentation describes itself as:

Swarm offers an innovative approach to packaging and running Java EE applications by packaging them with just enough of the platform to “java -jar” your application.

Deploying an Java EE application as a Swarm application is fairly straightforward:

  1. Add dependencies on the aspects of WildFly Swarm that you are to use to your project’s pom.xml file, for example, JAX-RS or JPA.
  2. Add the WildFly Swarm plugin to your project’s pom.xml file to enable an executable Jar file to be created.
  3. Sit back, relax and run your application as a standalone executable Jar !

To give a demonstration of how easy this is, I’ve created a very simple JAX-RS web service that returns a list of fruits - very similar to the Angular.js factory I created a few years ago.

The code for this sample application is available on GitHub

To create a JAX-RS web service and run as a WlidFly Swarm application, we just need to add the wildfly-swarm-jaxrs dependency. All of the dependencies that can be used with WildFly Swarm are documented in the User’s Guide

1
2
3
4
5
6
7
8
9
10
11
12
13
<properties>
<swarm.version>1.0.0.Alpha5</swarm.version>
</properties>

<dependencies>
...
<dependency>
<groupId>org.wildfly.swarm</groupId>
<artifactId>wildfly-swarm-jaxrs</artifactId>
<version>${swarm.version}</version>
</dependency>
...
</dependencies>

Adding the WildFly Swarm plugin to your pom.xml to create an executable Jar file is equally simple.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<plugins>
...
<plugin>
<groupId>org.wildfly.swarm</groupId>
<artifactId>wildfly-swarm-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>package</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>

All you need to do now, is perform a mvn package command to create an executable Jar file which you can start by executing java -jar myJar.jar

When creating and running a Swarm application, it’s important to note that the URL for the application will be different from when running inside a standalone application server.

When the application is deployed under an application server, the context path with usually include the name of the deloyed application, for example:

1
http://localhost:8080/swarm-rs-1.0-SNAPSHOT/api/fruit

When this is deployed as a Swarm application, the context path is not required (there is only one Java EE application running), so the URL will look something more like:

1
http://localhost:8080/api/fruit