What is a Security Realm?
A security realm in Payara Server is a component used to authenticate users. Despite all the complicated terminology used in Java EE security, which is not helped by different application servers having their own terminology to describe the same thing, that's fundamentally all it is. The 'certificate' realm is a Payara Platform-specific component used to authenticate users using a certificate store. This will be used, for example, in client certificate authentication.
Kubernetes is most commonly used with Docker managed containers, although it doesn't strictly depend on it. Kubernetes defines a Container Runtime Interface (CRI) that container platforms must implement in order to be compatible. These implementations are colloquially known as "shims". This makes Kubernetes platform agnostic so that instead of Docker you're free to use other platforms with corresponding shims, such as CRI-O or KataContainers.
Payara Platform 5 brought with it an implementation of Servlet 4.0, which itself contains support for the HTTP/2 standard. HTTP/2 support in Java has been fairly obscure for JDK 8 users, causing issues for many depending on their JDK minor version. This blog hopes to clarify the state of HTTP/2 in Payara Platform 5.
As of this month, there will no longer be any public JDK 8 releases. This means that security fixes won't be publicly accessible. A Payara support contract lets you take advantage of Payara's partnership with Azul, providing you with access to Zulu Enterprise. This means that you will have access to all future JDK 8 security fixes. Below are some common questions we receive regarding Zulu Enterprise and how it works with a Payara support contract.
JConsole is a useful tool for monitoring Java processes. You can collect data from a Java process such as: heap memory usage, thread count, CPU usage, classes loaded and MBean data. This allows you to gauge whether any Java process is using too much system resources. This guide will show you how to monitor Payara as a local process (on the same machine), or a remote process. This blog will assume that you've got a valid JDK and Payara install.
*Note: This blog post is an update to Dynamic Clustering and Failover on Payara Server With Hazelcast, which was written for Payara Server 4.
This article continues our introductory blog series on setting up a simple deployment group with Payara Server, carrying straight on from our last blog where we configured sticky sessions for Payara Server.
*Note: This blog post is an update to Configuring Stick Sessions for Payara Server with Apache Web Server, which was written for Payara Server 4.
This article continues our introductory blog series on setting up a simple deployment group with Payara Server, carrying straight on from our last blog where we set up a load balancer for our deployment group.
Note: This blog post is an update to Creating a Simple Cluster, which was written for Payara Server 4.
Continuing our introductory blog series, this blog will demonstrate how to set up a simple Hazelcast deployment group containing two instances. Deployment groups were introduced with Payara 5 to replace clusters. They provide a looser way of managing servers, allowing instances to cluster by sharing the same configuration whilst providing a single deployment target for all of them. See here to read more about Deployment Groups.