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
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:
--postbootcommandfile which can
be used as follows:
- Pre-boot Commands
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
- Post-boot Commands
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:
Deploying to a Server Already Started
To deploy via the CLI once the server has already started, use the 'deploy' asadmin command.
asadmin> deploy /path/to/file
All of the glassfish deploy options apply.
- Payara Specific Options
--skipdsfailure (Since Payara Server 18.104.22.168). 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.
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.
asadmin> deploy-remote-archive url
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.
asadmin> deploy-remote-archive --additionalRepositories repo1,repo2,…,repoN groupId,artefactId,versionNumber
asadmin> deploy-remote-archive --additionalRepositories https://google.co.uk,https://raw.github.com/Pandrex247/Payara_PatchedProjects/Payara-Maven-Deployer fish.payara.testing,clusterjsp,1.1
asadmin> deploy-remote-archive --additionalRepositories https://raw.github.com/Pandrex247/Payara_PatchedProjects/Payara-Maven-Deployer fish.payara.testing,clusterjsp,1.1
asadmin> deploy-remote-archive --target instance1 fish.payara.testing,clusterjsp,1.1
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.