This page provides some general information about the Payara Project.

Release Strategy

Payara project has a public release every quarter. Each release incorporates fixes and enhancements from the Payara team, GlassFish upstream, and the community.

Naming Strategy

The Payara Server naming strategy works off of the pre-existing GlassFish naming strategy: Append the year and quarter as the final dot version of the release. For example, for the Payara Server’s release built on GlassFish 4.1, released in quarter 3 of 2015, the version number would be payara-4.1.153.

In the case of updates, we will simply attach an additional point number to the end of the version number described above. For example, if a patch is released for Payara 4.1.152, the version number would be 4.1.152.1. This will be in addition to any extra point releases that Oracle do for GlassFish, so it’s possible for a version number to be something like 4.1.1.152.1!

Releases made to date include:

2018 Q1 - Payara Server 5.181 2018 Q1 - Payara Server 4.1.2.181

2017 Q4 - Payara Server 4.1.2.174 2017 Q3 - Payara Server 4.1.2.173 2017 Q2 - Payara Server 4.1.2.172 2017 Q1 - Payara Server 4.1.1.171

2016 Q4 - Payara Server 4.1.1.164 2016 Q3 - Payara Server 4.1.1.163 2016 Q2 - Payara Server 4.1.1.162 2016 Q1 - Payara Server 4.1.1.161

2015 Q4 - Payara Server 4.1.1.154 2015 Q3 - Payara Server 4.1.153 2015 Q2 - Payara Server 4.1.152 2015 Q1 - Payara Server 4.1.151

2014 Q4 - Payara Server 4.1.144

Work Strategy

Since Payara Server 4.1.152

We currently have a set strategy to balance receiving the latest Glassfish upstream changes with a need to avoiding making late changes to a release.

Change Freeze

Two to three weeks before a release, we will implement a change freeze. This means that no new features or changes will go into the coming release of Payara Server.

The remaining two to three weeks will be used for finding any bugs brought on by changes and fixes implemented for the coming release. If any bugs are found, these will be corrected before the release; if we can’t fix it before the release date, we will simply revert the change that caused the bug (pending a review).

GlassFish Upstream Cherry-Pick

We aim to do three cherry picks from the GlassFish upstream for each release: just after a release; at the beginning of the penultimate month of the release; and again at the beginning of the final month of the release (before the change freeze). + This to allow us time to find and fix any errors that may be brought in from the GlassFish upstream.

If a bug fix is committed to the GlassFish upstream during our change freeze, we will consider pulling in that solitary commit before the release.

GitHub

The Payara project is hosted on GitHub, allowing us to make use of the various tools GitHub has integrated for managing projects.

GitHub also makes allowing the community access to view and edit the source code very easy and public.

How to Contribute

We make use of the Fork and Pull model. This means that if you want to make any changes, you’ll need to fork the Payara project and make your changes in your own repository. You will then need to create a pull request back into the Payara project’s master branch to merge your changes into the main project.

Before we merge your pull request though, you must read and sign the Individual Contributor License Agreement (CLA) before sending it to us at the address specified on the document, or as an email attachment to cla@payara.org.

Once we’ve received the CLA and checked it for any mistakes, we’ll allow any pull requests you’ve made to start being merged.

In most cases, pull requests will not be merged immediately. This is to allow the Payara team, and other members of the community, to review and deliberate over any of the changes made; we will typically wait 2-3 days before merging any pull requests.

Issue Tracking

We make use of GitHub’s integrated issue tracker to allow the community to create enhancement and bug fix requests. The only requirements to create a bug fix or enhancement request is a GitHub account, and a reproducible bug or idea for an enhancement; you do not need to sign the CLA to create an enhancement or bug fix request. We also provide an Issue Template that can help you describe bug reports or enhancement requests in an easier manner.

Someone on the Payara team, or someone from the community, will then investigate and converse with you about the enhancement request or bug report.

We also attach labels and milestones to issues to help both us, and the community, manage the workflow of these issues.

Documentation

We make use of GitBook to store and host our technical documentation about Payara, as well as general information (such as this document) about the Payara project.

For technical documentation, we only store documentation that we have written, which typically pertains to new or modified features and commands made by us or the community; we do not host GlassFish documentation, nor will we rewrite it for unmodified modules.

Payara Server began life in 2014, derived from GlassFish 4.1. Since then, Payara Server has been refined with bug fixes, enhanced with new features, and has grown a strong community following. The documentation here will be updated with all the significant changes made with each new release.

Payara Server Documentation

The documentation of Payara Server distribution. Provides information about configuring and administering Payara Server, as well as how to deploy applications and how to use provided resources in deployed applications.

Payara Micro Documentation

The documentation of Payara Micro edition, which is a single file runtime capable of running applications from the command line. Payara Micro is designed to run applications in cloud and containerized environments a well as in embedded and IoT devices. It provides most of the functionality of Payara Server, adding some specific features for flexible deployments and ease of use.

Documentation of Payara Server features. Includes full documentation of the features added on top of GlassFish Server {{ book.glassfishVersion }} Open Source Edition as well as features shared with GlassFish Server or their improvements specific to Payara Server.

All documentation for GlassFish Server {{ book.glassfishVersion }} is also valid for Payara Server {{ book.currentVersion }} unless stated otherwise in Payara Server documentation.

HTTP in Payara Server is composed of several configuration layers:

• A transport. The default transport is tcp.

• An HTTP protocol. One of the default protocols is http-listener-1 (which has the same name as the http-listener-1 network listener).

• A network listener. One of the default listeners is http-listener-1.

• A virtual server. The default virtual server is server.

The configuration for each of these objects can be found in their respective pages:

Payara Micro Documentation

This section covers how to use Payara Micro.

Payara Micro is an embedded release of Payara built from the Payara Embedded Web release. It allows you to deploy and run WAR files from the command line with a single command, and also features automatic, dynamic clustering with Hazelcast.

Documentation Conventions

1. Any commands listed will be written assuming they are being run from the same directory as the Payara Micro JAR file.

2. Any commands listed will also be written assuming that the system environment variables have been set up to have Java on the system Path.

3. Any paths listed throughout the documentation will use the Unix/Linux file path structure (forward slashes).

4. The owning class of an API method will not be explicitly stated unless it is not clear if an instance has been started or not; methods that operate on Payara Micro instances before they have been bootstrapped (instances that have not yet been started) are contained in the PayaraMicro class, whereas methods that operate on bootstrapped instances (running instances) are contained within the PayaraMicroRuntime class.

Root Configuration Directory

Payara Micro is distributed as a single .jar file. However, at runtime, it creates and depends on a folder structure that is referred to as Root Configuration Directory or rootdir.

This directory stores all of the instance configuration, deployed applications, as well as implementation .jar files needed for running the instance.

Temporary Root Configuration Directory

By default, Payara Micro will create a folder in the system’s temporary directory and prepares a root configuration directory there. This makes instances' configuration stateless, but also has two potentially undesirable effects:

• Temporary directory may be deleted by system cleanup procedure. It is therefore important not to use a temporary directory in production scenarios. If files are removed by a third party process, the application will not behave correctly anymore.

• Preparing the directory has an impact on startup time

Persistent Root Configuration Directory

Root configuration directory can be explicitly specified with the command line parameter --rootDir <directory>. In such case, the directory is created only once, and instance configuration is preserved across restarts of the instance.

Following configuration is preserved:

• Deployed applications

• Effects of preboot, postboot and postdeploy commands

• Logging configuration

Documentation about Payara Server specific configuration properties.