One of the biggest challenges when developing applications for the web is understanding how applications need to be fine-tuned when releasing them into a production environment. This is no exception for Java Enterprise applications deployed on Payara Server.

The capability to disable implicit CDI scanning was already added to the previous Payara Server releases but the default admin console setting was to enable it at deploy time. We have now made a change so that the value added to the deployment descriptor is the overriding setting and the admin console setting will be ignored.

For even more control, we have added the ability to explicitly include or exclude JARs within an Application Deployment from CDI scanning. You can now, for example, include all JARs by default and exclude some named ones, or do the opposite and exclude all by default and only include some named ones.

In this three-parts article series I'm illustrating the implementation of the LDAP integration using a sample scenario: integrate Payara Server with a LDAP user directory and manage the authentication and authorization of a sample web application.

In Part 1, I showed you how to start the LDAP Server, while in Part 2  we configured the LDAP realm. Now you are probably wondering how to get the user’s information (first and last name, email address, etc.) that resides in the LDAP server. Unfortunately, the JAAS API doesn’t offer any standard mechanisms to access this user attributes in the directory tree. But there are other options available:

See 'Part 1 - Configuring the LDAP Server' here.

In this three-parts article series I will illustrate the implementation of the LDAP integration using a sample scenario: integrate Payara Server with a LDAP user directory and manage the authentication and authorization of a sample web application.

If you work in an organization with a robust IT department, it's very likely that you are using a LDAP server to handle your user directory information. You probably have to follow some general guidelines dictating that all web applications deployed within the organization’s infrastructure must access this user directory; and must authenticate and authorize the users that will interact with them. This is a very common scenario nowadays.

In order to fine tune a HTTP listener, the Payara Server administration console provides the means to configure a wide range of options. Besides the basic configuration available for a HTTP listener in the HTTP service section, it is also possible to set low-level configuration details in the HTTP tab of the same network listener in the Network-Config section.

As you probably know, Payara Server was created as an effort to fill the gaps that Oracle left when they dropped commercial support offerings for Glassfish Open Source Edition 4.x versions. However, our goal at Payara Services is not only to fill these gaps in support, but to strengthen the Community around Payara and GlassFish as well. For this to happen, we encourage all Payara Server & Payara Micro users to contribute to the Community - and there are a couple of ways to do so.

With this article, I'm going to integrate Payara Embedded with Arquillian by having it defined inside a sample Maven based application - source code available here - which employs an integration test implemented by the Arquillian framework.  You can also find our previous post about Arquillian and the Payara Server available here, but this time I’ll take it one step further and move onto the IDE side. In this example, I will execute tests just like any JUnit test; meaning the test will be executed directly through the IDE with help of a right-click. I will also configure Payara Embedded as the Arquillian container inside the IDE.

Have you ever wondered whether your application is slow to respond to requests? Which requests take the longest to respond to? And what you can do about it? Payara Server aims to provide the best tooling you would need to identify performance issues, identify their causes and help you solve them. One part of this tooling is the new Request Tracing service, available in Payara Server and Payara Micro from version 163 as a technical preview.

TIP: Don't deploy any apps to the DAS in production!

Why?

As is the case with all my stories, this one began at a customer site. They had an old app they were migrating from GlassFish 3.1.2 to the latest version of Payara Blue. They'd called me in because they wanted to benchmark performance of the new version of Payara Blue on AIX against their existing GlassFish 3.1.2, also on AIX, as well as against a recent version of JBoss (I'm unsure of the version, though I know it was deployed on Windows).