Skip to content

When deploying an application to Payara Micro, the default context path for any web resources is defined by the name of the archive.

For example, if I deploy the archive PayaraRest-1.0-SNAPSHOT.war, the context root is defined as /PayaraRest-1.0-SNAPSHOT

$ java -jar payara-micro.jar --deploy  PayaraRest-1.0-SNAPSHOT.war
[Payara Micro 4.1]  Loading application [PayaraRest-1.0-SNAPSHOT] at [/PayaraRest-1.0-SNAPSHOT]

There are a few techniques however for changing the context of deployed applications in Payara Micro.

File Name

The simplest way of changing the context of a deployed application is to change the name of the archive being deployed. The context will be set to the name of the archive, for example:

$ mv target/PayaraRest-1.0-SNAPSHOT.war target/Renamed.war

$ java -jar payara-micro.jar --deploy target\Renamed.war
[Payara Micro 4.1]  Loading application [Renamed] at [/Renamed]


The context of a web application can also be changed using the standard Payara configuration xml, by adding an entry into the glassfish-web.xml file within the project.

<glassfish-web-app error-url="">
$ java -jar payara-micro.jar --deploy  PayaraRest-1.0-SNAPSHOT
[Payara Micro 4.1] Loading application [PayaraRest-1.0-SNAPSHOT] at [/PayaraRest]

Deploying via Code

Using Java code, it's relatively straightforward to deploy an application using a few lines of code. First of all, add the dependencies to Payara Micro into your pom.xml


Applications can then be deployed by creating an instance of a PayaraMicroRuntime and calling its deploy() method. This method takes the name and the context path to deploy:

package com.davidsalter.payaradeployer;

import fish.payara.micro.PayaraMicro;
import fish.payara.micro.PayaraMicroRuntime;

public class Main {

    public static void main(String[] args) throws Exception {
        PayaraMicroRuntime instance = PayaraMicro.bootstrap();
        InputStream is = new FileInputStream("<path to>\PayaraRest-1.0-SNAPSHOT.war");
        instance.deploy("PayaraRest", "Programatically", is);
[Payara 4.1] Loading application [PayaraRest] at [/Programatically]

/ Deployments

One final point to note is that if you wish to deploy an application at the root context /, this can be achieved by renaming the deployment ROOT.war

$ mv target/PayaraRest-1.0-SNAPSHOT.war target/ROOT.war

$ java -jar payara-micro.jar --deploy target\ROOT.war
[Payara Micro 4.1] Loading application [ROOT] at [/]


In this article, I've shown a few different techniques for changing the deployment context for web applications in Payara Micro. Hopefully you'll agree that these simple techniques can allow you to make useful changes to your microservice deployments.

There are many different frameworks that allow you to develop and deploy microservices. Payara, the team behind the Payara Server have a couple of options for deploying microservices - PayaraMicro and Payara MicroProfile. So, what exactly are PayaraMicro and Payara MicroProfile?

What is Payara Micro?

Both PayaraMicro and Payara Microprofile are small .jar files that allow you to deploy .war files from the command line allowing Java EE applications to be easily executed.

PayaraMicro is described as:

small, <70 MB in size and incredibly simple to use. With its automatic and elastic clustering, Payara Micro is designed for running Java EE applications in a modern containerized/ virtualized infrastructure, using automated provisioning tools like Chef, Ansible or Puppet.

and supports the following Java EE APIs.

  • Servlets, JSTL, EL and JSPs
  • WebSockets
  • JSF
  • JAX-RS
  • EJB lite
  • JTA
  • JPA
  • Bean Validation
  • CDI
  • Interceptors
  • JBatch
  • Concurrency
  • JCache

Payara MicroProfile follows the MicroProfile initiative led by IBM, the London Java Community, RedHat, TomiTribe, Payara and SOUJava and provides support for the following APIs.

  • JSON-P
  • CDI
  • JAX-RS

Essentially, Payara MicroProfile is a cut down version of Payara Micro.

OK, so we've got a pretty good understanding of what Payara Micro / MicroProfile are, but how can they be used to deploy Java EE applications?

Downloading Payara Micro

Both installations can be downloaded as a .jar file from Payara's web site. The downloads are based on the full version of Payara Server, which is in turn based on the latest version of GlassFish 4.

Deploying onto Payara Micro

To deploy and run an application using Payara Micro (from hereon, when I refer to Payara Micro, I mean Payara Micro or Payara MicroProfile), we execute Payara Micro and tell it to deploy the application. This is different from technologies such as WildFly Swarm, which requires application specific APIs to develop and deploy the application.

For example, to deploy a JAX-RS application in WildFly Swarm, we need to build and deploy with the appropriate Swarm artifacts:


With Payara Micro, this is not necessary - the only dependency we have is Java EE itself.


Starting up Payara Micro and deploying an application is a case of executing the following command:

java -jar payara-micro- --deploy <app.war

where <app.war> is the path to the .war file to deploy.

[2016-12-29T21:41:37.471+0000] [Payara Micro 4.1] [INFO] [] [PayaraMicro] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1483090897471] [levelValue: 800] Deployed 1 archives

[2016-12-29T21:41:37.472+0000] [Payara Micro 4.1] [INFO] [] [PayaraMicro] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1483090897472] [levelValue: 800] Payara Micro #badassmicrofish (build 28) ready in 17990 (ms)

That's all there is to it. We can easily start Payara Micro and deploy a .war file to it without having to add any specific MicroProfile content into the codebase.

As a word of caution, it's worth noting the APIs that Payara Micro supports however. For example, if you try to use JAX-WS, the chances are your application won't deploy and won't work! Stick to the supported API's and you should be ok.

Creating an UberJar Distribution

We've just seen how to start and deploy an application using Payara Micro. We can also use Payara Micro to create an UberJar if we wish to distribute applications as a single .jar

Creating the UberJar is simply a matter of appending the relevant command line parameters onto Payara Micro.

$ java -jar payara-micro- --deploy <app.war> --outputUberJar MyApp.jar
Dec 29, 2016 22:12:58 AM fish.payara.micro.PayaraMicro packageUberJar
INFO: Building Uber Jar... MyApp.jar
Dec 29, 2016 22:13:14 AM fish.payara.micro.PayaraMicro packageUberJar
INFO: Built Uber Jar MyApp.jar in 15439 (ms)

Command Line Options

In this post, we've just looked at a couple of the command line parameters to Payara Micro (--deploy and --outputUberJar). There are many more parameters that can be used for example, setting the HTTP port or maximum number of HTTP threads. Details of these options are provided on the Payara Micro wiki


Payara Micro is a lightweight way of executing Java EE applications supporting the relevant APIs. It's easy to use, but provides flexibility and many of the features of it's big brother - Payara Server.

A few days ago, the WldFly Swarm team announced the release of the 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 favourite 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.

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

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.

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

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.

$>heroku create
Creating app... done, stack is cedar-14 |

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 in the root of the project containing a single line indicating the version of Java required.


How To Execute The Application

Heroku uses a Procfile to determine how your application should be executed. 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

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 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.

$>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: -----> Compressing...
remote:        Done: 96.9M
remote: -----> Launching...
remote:        Released v4
remote: deployed to Heroku
remote: Verifying deploy.... done.
 * [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.


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

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:


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


It's 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.