Payara Tools 1.0 – New and Noteworthy

A convenience option has been added to let you choose the main folder of a Payara installation in addition to the embedded Glassfish folder.

Before:

 Now:

The stop button displayed in the progress view when launching Payara used to be a NO-OP, causing the UI to get stuck whenever Payara would not respond anymore during launching. Now it disconnects Eclipse from the launch process.

Support for JDK range patterns in domain.xml

Payara 5.184+ uses JDK patterns in its domain.xml file. These weren’t recognised before, causing startup to fail. Now they are supported, and additionally the plug-in scans which Java version Payara is actually using.

JDK conditional JVM options in domain.xml:

Earlier versions of the plug-in were not processing these, leading to errors like:

It’s now possible to navigate directly to the final assembled module (for instance a .war file for a web application) as it is deployed to Payara. This can be useful for troubleshooting purposes.

Select the deployed module, then choose Show in and then Open in File Browser:

The OS file browser will show the assembled module:

From a deployed module underneath a server instance it’s now possible to navigate back to the source project corresponding to this deployed module.

Select the module, then click on Goto Project:

The associated project is now highlighted and opened in the project explorer:

All domain files associated with a Payara Server runtime are now shown directly in  a project in the Eclipse workspace:

Earlier versions of the plug-in did not support installations of Payara with a space in its path. This is now supported:

Hot deployments were possible before, but changes to .java files triggered a server restart, even though some changes can be safely hot deployed. The file pattern that triggers a restart is now configurable and has been defaulted //.jar$ (meaning the application will restart when a jar file changes):

The default mode for the debugger is boot up Payara Server fully and then attach. For debugging applications this is usually fine, but for debugging complex behaviour involving server internals this may be too late. There is now an option to start Payara in suspended mode, attach the debugger immediately and then continue booting Payara:

The plug-in depends on a dependency called “Sapphire”, which wasn’t correctly declared in older versions of the plug-in, yet Eclipse was able to find it in Eclipse 4.8 and earlier. From Eclipse 4.9 onwards installation would complain with:

Cannot complete the install because one or more required items could not be found.

Software being installed:
    Payara Tools 1.0.0.201804032346

    (org.eclipse.payara.tools.feature.group    

     1.0.0.201804032346)

Missing requirement:
    Payara Tools 1.0.0.201804032346  

    (org.eclipse.payara.tools.feature.group

    1.0.0.201804032346)

    requires

        ‘org.eclipse.equinox.p2.iu;  

        org.eclipse.sapphire.modeling.xml.feature.group

        [9.1.0,10.0.0)’

    but it could not be found

This has now been fixed.

While Payara itself does not run on JDK 11 yet, the following exception was thrown when running Eclipse on JDK 11 and trying to start Payara 5.191 (Payara running on JDK 8):

java.util.MissingResourceException:

Can’t find bundle for base name sun.util.logging.resources.logging, locale en_US
  at java.base/java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:2045)
  at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1679)
  at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1583)
  at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1546)
  at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:914)
  at org.eclipse.payara.tools.log.LevelResolver.getLocalized(LevelResolver.java:58

This has now been fixed.

When using Payara as a target runtime (as is common for a native Eclipse project instead of e.g. a Maven or Gradle project) a selected number of libraries (jars) from mostly the /modules folder of a Payara installation is added to the class path of a project. In Payara 5.191 some of the jar names changed, mainly from javax.* to jakarta.* causing compilation errors in projects depending on these.

This has now been fixed, and the jakarta.* libraries appear in the list of libraries underneath the Payara library container:

The Payara library container keeps an internal list of file patterns for each supported Payara version. If libraries change in newer Payara versions than the plugin supports, (native) projects may not work anymore. As a fallback, there is now a switch to put all libraries from a target Payara installation on the class path:

Open the properties:

Then select the variant: