Application Deployment

Applications can be deployed to Payara Server in the same way as GlassFish Server 4.1 Open Source Edition. Payara Server does not modify this process but does add some new features to deployment descriptor files which are documented in the following pages.

Deploying on Server Start

GlassFish has had the ability to deploy applications on server start for a long time now, using the autodeploy directory. While acceptable in development environments, the scanner used to deploy files in this directory is a security risk for production and is therefore disabled in the production domain bundled with Payara Server.

To reintroduce the capability of deploying an application on server startup without the risk of enabling the deployment scanner, a feature from Payara Micro was introduced: the ability to run asadmin commands at startup, either pre or post boot.

To enable this feature, we have extended the start-domain feature to accept two extra options: --prebootcommandfile and --postbootcommandfile which can be used as follows:

Pre-boot Commands

Usage: asadmin> start-domain --prebootcommandfile=/path/to/file

Aim: passing a list of commands as a file to the server to run pre-boot. Due to the time during boot when the commands in this file are executed, this only supports set commands.

Post-boot Commands

Usage: asadmin> start-domain --postbootcommandfile=/path/to/file

Aim: passing a list of commands as a file to the server to run post-boot. This is where commands such as service configuration commands should be run.

There are some important caveats to note:

  • Both files should be saved in a text format, with each command on it’s own line.

  • Lines where the first non-whitespace character is # are treated as comments

  • Any blank lines will be ignored

  • Any invalid or failing commands will be logged to the server.log and the file will continue to be processed

  • The files must exist, and be accessible from Payara Server.

  • Both pre-boot and post-boot files can be passed at the same time.

Deploying to a Server Already Started

To deploy via the CLI once the server has already started, use the 'deploy' asadmin command.

Usage: asadmin> deploy /path/to/file All of the glassfish deploy options apply.

Payara Specific Options

--skipdsfailure (Since Payara Server 4.1.2.173). This option will skip over a datasource failure. This means an application can be deployed with a datasource set up, but the database need not be running at the time. Without this option the deployment would fail if a datasource is defined and the database is not available.

Example: asadmin> deploy --skipdsfailure /home/mark/clusterjsp-1.1.war

Deploying from a URL

GlassFish and Payara embedded have had the ability to deploy applications from a URL for a while, and this feature has now been brought into Payara Server. To faciliate this new feature, a new asadmin command was created: deploy-remote-archive. This command takes all of the same parameters as the standard deploy command, and is used in exactly the same way - the only difference is in the command name, and the fact you specify a URL instead of a file.

Usage: asadmin> deploy-remote-archive url

Example: asadmin> deploy-remote-archive https://raw.github.com/Pandrex247/Payara_PatchedProjects/Payara-Maven-Deployer/fish/payara/testing/clusterjsp/1.1/clusterjsp-1.1.war

At this point in time, the command will only accept HTTP and HTTPS URLs.

Deploying from a Maven Repository.

The feature of Payara Micro to deploy applications from a Maven Repository using their Group, Artefact, Version (GAV) coordinates has also been brought into Payara Server. This functionality uses the same command as when deploying from a URL: deploy-remote-archive. This command takes all of the same parameters as the standard deploy command, but has an extra parameter:

  • additionalRepositories - This parameter accepts a comma separated list of repository URLs, that will be probed when searching for an artefact. By default, the command will only look in Maven Central.

Usage: asadmin> deploy-remote-archive --additionalRepositories repo1,repo2,…​,repoN groupId,artefactId,versionNumber

Examples:

If you don’t specify a name or context root for the artefact when deploying using GAV coordinates, it will just be the artefact name (in the example above, it would be clusterjsp).

If an application matching the GAV coordinates exists on multiple repositories, the first found will be deployed. The order that the repositories are searched is the order that you specify them in. For example, given an additionalRepositories of repo1,repo2, the order that the repositories would be searched is: Maven Central > repo1 > repo2.

Although the command accepts Maven GAV coordinates, it does not actually make use of Maven, and so artefacts will not be saved into your local maven repository.