What's New in Payara Server & Payara Micro 5?

Payara Server 5 and Payara Micro 5 are here! We've already blogged about some improvements in Payara Server & Payara Micro 5, but there are many more. 

We know you'll be excited to find that this release includes several usability improvements making Payara Server & Payara Micro's architecture even more innovative, microservices-ready, cloud-native and optimized for production deployments.

Domain Data Grid

We have covered the new Domain Data Grid in other posts, like Steve's introduction and the preview blog earlier this month. Despite that, it is still worth another mention since it's such a significant change! The key takeaway is outlined very succinctly in Steve's blog:

In Payara Server 5, all Payara Server instances in a domain will form a single domain-wide data grid and data will be shared across all instances transparent to the developer. This data grid, in the majority of cases, will require zero or very little configuration - it will just happen. Data stored in the grid is duplicated across 1 or more instances for high availability and the more instances that are added the more JVM Heap is available for in-memory data storage. This allows the grid to scale to large data sets by adding more Payara Server or Payara Micro instances without loss of performance on updates or retrievals.

Deployment Groups

An important practical difference this makes when working with Payara Server 5 and Payara Micro 5 is the new concept of Deployment Groups which replaces the concept of Clusters.

What were the responsibilities of a cluster have been split out into several areas:

• Domain wide data sharing
• A single target for deployment and configuration management
• A unit of data sharing for web sessions and SSO credentials

The Domain Data Grid handles the backbone data sharing, while the deployment group now takes on the dual responsibilities of being a single target to deploy an application to and a single, logical unit to divide up the data sharing usage.

Functionally, a deployment group can be used in largely the same way as a cluster, with data replication being taken for granted within the domain.

Request Tracing Overhaul

The Request Tracing service, introduced in the 163 release, has been overhauled. It is now in an OpenTracing-style format (using spans instead of events) and has sampling capabilities added (flat probability and an adaptive solution). In addition, it now has two separate stores: the "working / rolling" store, and the existing historical one.

Support for Java EE 8 Applications

Payara Server and Micro have been updated with GlassFish 5 and Java EE 8 applications are fully supported, which includes major updates to APIs like Servlet 4.0 which provides HTTP/2 support, Bean Validation 2.0 and CDI 2.0. Even minor, "point" upgrades have significant changes, with JAX-RS 2.1providing a new reactive client API, and JSF 2.3 providing WebSocket support and featuring a new component search expression framework.

In Payara Server 5 and Payara Micro 5 a special build of Mojarra (the JSF 2.3 reference implementation) is included that is capable of initialising Mojarra in parallel when the fish.payara.faces.enableParallelInit context param in the web.xml is set to true. Depending on the size of the application being deployed and the number of available cores this may improve startup performance.

A special build of Soteria (Java EE Security reference implementation) is included as well, which fixes a small bug (ArrayIndex exception with null password in Basic authentication) and prevents some unnecessary warnings in the log.

Note: There is a known issue with HTTP/2 support, raised in the GlassFish GitHub repository:

With Glassfish 5.0 the behaviour of HttpServletRequest.getServerName() and also HttpServletRequest.getServerPort() changed to return the same value as HttpServletRequest.getLocalName() resp. HttpServletRequest.getLocalPort().

MicroProfile 1.2 Support

Payara Server and Payara Micro 5 include an update for compatibility with MicroProfile 1.2 , with the following APIs:

• JAX-RS 2.0
• CDI 2 (updated 1.2 → 2)
• JSON-P 1.0
• Annotation 1.2
• Microprofile Config 1.1 (updated 1.0 → 1.1)
• Microprofile Fault Tolerance 1.0 (new)
• Microprofile Health 1.0 (new)
• Microprofile Metrics 1.0 (new)
• Microprofile JWT Propagation 1.0 (new)

For more details on the specifics of each API, visit microprofile.io, or view each API on GitHub.

A New Look Admin Console

The Admin Console has a brand new dark theme! This is really just a cosmetic change - everything still works in the same way as before - but is now more in line with the Payara Server brand and is a very clear indicator that you're running Payara Server 5, not Payara Server 4.

The H2 Database Replaces Derby

There have been a number of issues in the past with the Derby database. Most users are aware that it's not good for production use, but we found that there were still issues which needed to be dealt with. Beginning with Payara Server 5, the H2 database is preferred, though Derby is deprecated for removal in the next release and only now included for compatibility.

New Hazelcast-Powered Features

EJB Timer Store Now in Payara Server

Since Payara Micro doesn't include any database, we made it possible to use the Hazelcast cache as a persistent EJB timer store. This feature is now available in Payara Server so that persistent timers can be stored in the Domain Data Grid.

Clustered Singletons

A new feature in both Payara Server 5 and Payara Micro 5 is the ability to create both CDI and EJB singletons across a cluster. This means that a singleton is guaranteed to have only a single instance across the cluster. Should the server which is hosting the singleton go down, another instance will resume the singleton. Since this means that the original bean has changed, there may be cleanup operations to do which would not get called since the "logical" singleton has not been destroyed, but the actual instance has changed. To handle this, the default behaviour is to call @PostConstruct each time the bean instance is created or destroyed on a different server instance, though this can be configured.

Java EE Security.Next prelude

Payara Server 5 and Payara Micro 5 include a CDI based variant of the well known RolesAllowed annotation, named RolesPermitted to avoid confusion. This annotation can be found in the Payara API (fish.payara.api:payara-api:5.181) and can be used to secure CDI based business methods. Note that JAX-RS resources can use both RolesAllowed and RolesPermitted, with the difference that RolesAllowed can cause a challenge to be sent when the caller is not authenticated, while RolesPermitted will always throw an exception.