What's New in Payara Server 162?

Originally published on 06 May 2016
Last updated on 06 Jan 2020

The second release of 2016 is finally here! Payara Server 4.1.1.162 is our biggest release yet in terms of sheer number of bug fixes and new features. One of the biggest things isn't actually a new feature of Payara Server but a newly rehosted documentation, and it's where you'll find the full release notes for this version.

Outside of the Server itself, we have a couple of new things – e.g. updated documentation and improved Docker images in Docker Hub. These aren't small improvements, so we will dedicate separate blog posts to these!

New Developers

Within the team, we have new members to welcome – Fabio Turizo has joined the Support and Customer Service Team; and Lenny Primak has joined our developers. Lenny has been part of the team for a couple of weeks now and hasn't wasted time; two enhancements have been added by Lenny:

Disable CDI for and entire deployment in deployment descriptor

Implicit CDI scanning can cause problems sometimes. There is already a method to disable CDI scanning within a WAR file (WEB-INF/beans.xml attribute bean-discovery-mode="none"will disable CDI scanning for all WAR classes and in WEB-INF/lib directory) but there was no way to do this for EAR files. So if you included 3^rd party JARs in your EAR, it may still trigger implicit CDI scanning. Lenny added a tag to the glassfish-application.xml to disable CDI for an entire EAR.

Add support for overriding app server libraries using ScopedEARClassloader on domain level

Previously, it was possible to add new global libraries at the domain level, but it does not work if the same library is present as core Payara Server dependencies. The implemented behavior is that a new version of a library in domain/lib would override older version of the library inside the server. This is enabled by setting fish.payara.classloading.delegate = false (the default is true)

New Clustering Features

We already support more modern cluster topologies in Payara Server and Payara Micro through the use of Hazelcast (see more ). With this release, we have enabled Hazelcast "Lite" nodes in both Micro and Server editions. This means that you can have cluster members which share data, but have no local data storage. This means you can drastically skew your heap in favour of the new generation and, as a result, have much lower pause times! In addition to that, we have also enabled Payara Micro and Payara Server to join the same cluster.

An important improvement is that we now support Hazelcast group config and group password properties in the console. If you’re in a position where you go live to production with a Hazelcast cluster which has default settings, then previously there would be cross-talk with any other Payara Server instance that used Hazelcast on the same network. Our first recommendation is always to change the defaults, but using group configuration we can avoid accidents!

Stay tuned to this blog over the coming weeks, where we intend to go more in-depth in the advantages and disadvantages of these new styles of clustering and show how you can make the best use of them in cloud environments.

The new clustering feature I’m most looking forward to, though, is a new button in the admin console, and an asadmin command to go with it…

…because it was added by me! I’ve long been frustrated by the lack of a restart button at the cluster level, despite it being possible to restart individual instances. Now I know that my testing life is going to have one less frustration in it!

New Payara Micro Features

There have been quite a few Payara Micro improvements this month, so I’ll list the key ones here:

Payara Micro can now deploy your artifacts stored in Maven repositories simply by providing the GAV coordinates. This should provide another option for continuous delivery scripts!
Continuing the deployment theme, Payara Micro can now deploy exploded archives.
There is also now support for passing in a properties file to pass in system properties more easily.
At the build stage, you can now package a domain.xml in with your application. While certain parts of configuration can already be packaged with your application (like a data source, for example), you can now package a fully configured Payara domain. When you are developing microservices, packaging and deployment is often much easier if all the configuration is in one versioned unit, rather than a single deployment involving multiple files.
So far in the life of Payara Micro, our design goals have been to view a microservice as just a skinny WAR – in other words, just your business logic, not the runtime. This means that your artifacts are kept as small as possible and easy to manage. IT is never a one-size-fits-all game, though, and plenty of people really like packaging the WAR into a runnable “Uber” JAR, so we have now added a feature to output a runnable JAR as a command line option!

Community Fixes and Enhancements

As usual, the community effort has been very strong! Our thanks for this release go out to:

Patrik Duditš:

“ratcashdev”:

Payara not showing modules for versioned application PAYARA-670

and David Matějček:

And finally…

A special mention to all those who have been raising issues on GitHub! We’re very grateful for all the work in testing our new releases and quickly raising bugs. The more things we catch early, the better Payara Server becomes!

As mentioned above, keep an eye out for more blog posts explaining the new Payara Server and Payara Micro 162 features in more detail - all coming within the next couple of weeks. Make sure you don't miss them and subscribe to our blog ( top of this page).