Applications can be deployed to Payara Server in the same way as GlassFish Server 4.1 Open Source Edition. Payara Server Enterprise 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
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 188.8.131.52). 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
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.
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 Enterprise. 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.
Overwriting the Application Name
Since Payara Server 184.108.40.206 and 5.182
When deploying an application or a module on Payara Server Enterprise 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
--forcename options to override this behaviour.
Prior to 220.127.116.11 and 5.182