Application Deployment

Applications can be deployed to Payara Server in the same way as GlassFish Server 4.1 Open Source Edition. Payara Server Community does not modify this process but does add some new features.

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

Payara Embedded has the ability to deploy applications from a URL for a while, and this feature has now been brought into Payara Server. To facilitate 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 Community. 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.

Overwriting the Application Name

Since Payara Server 4.1.2.182 and 5.182

When deploying an application or a module on Payara Server Community from an IDE (like NetBeans or IntelliJ), the IDE deploys to Payara Server using the asadmin deploy command, with the --name option specified. This will force the application or module to have the specified name over the name defined in deployment descriptor. This is undesired because the IDE usually infers the application or module name from the name of the project or the package file and doesn’t take the correct name of the application or module into account.

To solve the issue, application or module name defined in the deployment descriptor will always take precedence over the --name option. But you use the --name and --forcename options to override this behaviour.

Prior to 4.1.2.182 and 5.182 --forcename option was only supported on EJB.