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.
{{cta(‘b54b05ee-8a96-4bb4-8f00-7a7625302e33’)}}
IMPORTANT: You will need at least JDK 8 to use Payara Server 5 or Payara Micro 5. If you need to upgrade your installation of Java, Azul provide free downloads of JDK 8: https://www.azul.com/downloads/zulu
{{cta(‘9d4e5ef0-09a3-4215-b22a-2b83f84dc7ca’)}}
Domain Data Grid
We have covered the new Domain Data Grid in other posts, likeSteve’s introductionandthe 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 ofDeployment Groupswhich replaces the concept ofClusters.
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 likeServlet 4.0which provides HTTP/2 support,Bean Validation 2.0andCDI 2.0. Even minor, “point” upgrades have significant changes, withJAX-RS 2.1providing a new reactive client API, andJSF 2.3providing WebSocket support and featuring a new component search expression framework.
In Payara Server 5 and Payara Micro 5 a special build ofMojarra(the JSF 2.3 reference implementation) is included that is capable of initialising Mojarra in parallel when the fish.payara.faces.enableParallelInitcontext 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.
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:
For more details on the specifics of each API, visitmicroprofile.io, or view each API onGitHub.
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, theH2 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.
Wow. But my application goes live on 29th of March, 2018..How long will it take to migrate on AWS Lightsail? Currently using Payara using payara-4.1.2.181 and JEE 7. Also, should I consider replacing websockets with HTTP2??
Being on AWS Lightsail shouldn’t make much difference. As far as I am aware, Lightsail is still essentially EC2, so doesn’t have any specific restrictions or changes. Personally, I would not consider a change like this so close to a go-live date!
If you decide to have a support contract, then we can continue to provide Payara 4 builds, but otherwise you will need to plan to migrate to Payara 5 at some point, since there will be no more public builds of Payara 4.
Replacing Websockets depends on how you are using them. They are great for bi-directional communication, but if you are only using them for server push, like a broadcast, then you could look at using the new JAX-RS 2.1 specification, which implements Server-Sent Events (SSE). I’m not sure how performance would change between Websockets and SSE, but I would be surprised if it’s significant enough to be worth the change (although sometimes very small fractions can be important). If what you have works for you, I would stick with that in the near-term.
Could you be more specific about “this data grid, in the majority of cases, will require zero or very little configuration – it will just happen”? If all developers in a team are using domain1, for example, we’ll share web sessions by default?
It depends what you mean. All web sessions will be available on all instances (though they may not physically be located there) but you won’t actually share the same web session.
Hi Ionut,
Payara 5 clustering will not interfere with clusters of other developers.
That’s one of the major features in Payara 5 because in Payara 4, Hazelcast-based clusters used multicast for discovery of other instances in the cluster and if multiple developers were on the same networks their instances would form a single cluster unless they specify a different cluster password.
In Payara 5, the default discovery mechanism is a custom Payara domain discovery which means that only instances specified in the domain configuration would form the cluster. You need to create new instances (e.g. via Admin console) and only those would be part of the cluster. It’s very similar to how the old clustering mechanism worked but it’s not running on Hazelcast on you can regroup instances after you created them.
The multicast discovery used in Payara Server 4 is supported but not enabled by default.
Hi Ondrej, the docs for 5.183 say that the default discovery mode for micro is still multicast – so I’m wondering which it is? However I can’t get it to work. Using micro 4 it works with no config, all members are listed in the “Members” list at startup. However with 5, the Instances output (presumably that terminology replaced Members?) only ever show one instance even though I start many.
Payara Micro 5 uses multicast for discovering the cluster, similar to Payara Micro 4. The behavior of Payara Micro 5 might be different because it uses a different behavior for selecting the default IP address (network device) for multicast. The default multicast port is also different, Payara Micro 4 uses 5900 while Payara Micro 5 uses 6900, so they won’t cluster together with default configuration.
When you start several instances of Payara Micro 5 with the following command:
java -jar payara-micro.jar –autobindhttp
all of them will most probably cluster together. If they don’t, please check that they picked the correct network device – the IP and port is in the Instances output. If they picked a wrong device, you may force Payara Micro 5 to use a specific network device with –mcaddress argument.
Welcome aboard the September issue of The Monthly Catch! With summer holidays wrapping up, the Java world is back […]
4 minutes
Uncategorized
Dominika Tasarz
25 Sep 2025
Leading the Way: Payara Platform Community 7 Beta Now Fully Jakarta EE 11 Certified
We’re excited to announce that Payara Platform Community 7 Beta application server is now fully certified as Jakarta EE 11 […]
6 minutes
Jakarta EE
Chiara Civardi
29 Aug 2025
What Is a Java Application Server? A Short Guide
Enterprise Java applications power global commerce, healthcare, government and countless other industries. These systems must be scalable, secure and […]
3 minutes
Thanks. The admin console is too dark. Can you provide an option to switch the background back to light?
Regards
I agree. It’s too dark.
Wow. But my application goes live on 29th of March, 2018..How long will it take to migrate on AWS Lightsail? Currently using Payara using payara-4.1.2.181 and JEE 7. Also, should I consider replacing websockets with HTTP2??
Hi Kunal,
Being on AWS Lightsail shouldn’t make much difference. As far as I am aware, Lightsail is still essentially EC2, so doesn’t have any specific restrictions or changes. Personally, I would not consider a change like this so close to a go-live date!
If you decide to have a support contract, then we can continue to provide Payara 4 builds, but otherwise you will need to plan to migrate to Payara 5 at some point, since there will be no more public builds of Payara 4.
Replacing Websockets depends on how you are using them. They are great for bi-directional communication, but if you are only using them for server push, like a broadcast, then you could look at using the new JAX-RS 2.1 specification, which implements Server-Sent Events (SSE). I’m not sure how performance would change between Websockets and SSE, but I would be surprised if it’s significant enough to be worth the change (although sometimes very small fractions can be important). If what you have works for you, I would stick with that in the near-term.
Thanks a lot for the advice Mike. Let Payara 5 mature a bit.I shall surely migrate.
Hi,
Could you be more specific about “this data grid, in the majority of cases, will require zero or very little configuration – it will just happen”? If all developers in a team are using domain1, for example, we’ll share web sessions by default?
Hi Ionuț,
It depends what you mean. All web sessions will be available on all instances (though they may not physically be located there) but you won’t actually share the same web session.
Hi Ionut,
Payara 5 clustering will not interfere with clusters of other developers.
That’s one of the major features in Payara 5 because in Payara 4, Hazelcast-based clusters used multicast for discovery of other instances in the cluster and if multiple developers were on the same networks their instances would form a single cluster unless they specify a different cluster password.
In Payara 5, the default discovery mechanism is a custom Payara domain discovery which means that only instances specified in the domain configuration would form the cluster. You need to create new instances (e.g. via Admin console) and only those would be part of the cluster. It’s very similar to how the old clustering mechanism worked but it’s not running on Hazelcast on you can regroup instances after you created them.
The multicast discovery used in Payara Server 4 is supported but not enabled by default.
Hi Ondrej, the docs for 5.183 say that the default discovery mode for micro is still multicast – so I’m wondering which it is? However I can’t get it to work. Using micro 4 it works with no config, all members are listed in the “Members” list at startup. However with 5, the Instances output (presumably that terminology replaced Members?) only ever show one instance even though I start many.
Hi Martin,
Payara Micro 5 uses multicast for discovering the cluster, similar to Payara Micro 4. The behavior of Payara Micro 5 might be different because it uses a different behavior for selecting the default IP address (network device) for multicast. The default multicast port is also different, Payara Micro 4 uses 5900 while Payara Micro 5 uses 6900, so they won’t cluster together with default configuration.
When you start several instances of Payara Micro 5 with the following command:
java -jar payara-micro.jar –autobindhttp
all of them will most probably cluster together. If they don’t, please check that they picked the correct network device – the IP and port is in the Instances output. If they picked a wrong device, you may force Payara Micro 5 to use a specific network device with –mcaddress argument.