General Runtime Administration

This chapter provides instructions for performing general administration tasks in the Payara Server environment by using the asadmin command-line utility.

Using the asadmin Utility

Use the asadmin utility to perform administrative tasks for Payara Server from the command line or from a script. You can use this utility instead of the Administration Console interface.

Path to the asadmin Utility

The asadmin utility is located in the as-install/bin directory. To run the asadmin utility without specifying the path, ensure that this directory is in your path.

asadmin Utility Syntax

The syntax for running the asadmin utility is as follows:

asadmin [asadmin-util-options] [subcommand [subcommand-options] [operands]]

The replaceable items in this syntax are described in the subsections that follow.

Subcommands of the asadmin Utility

The subcommand identifies the operation or task that you are performing. Subcommands are case-sensitive. Each subcommand is either a local subcommand or a remote subcommand.

  • A local subcommand can be run without a running domain administration server (DAS). However, to run the subcommand and have access to the installation directory and the domain directory, the user must be logged in to the machine that hosts the domain.

  • A remote subcommand is always run by connecting to a DAS and running the subcommand there. A running DAS is required.

asadmin Utility Options and Subcommand Options

Options control the behavior of the asadmin utility and its subcommands. Options are case-sensitive.

The asadmin utility has the following types of options:

asadmin utility options

These options control the behavior of the asadmin utility, not the subcommand.

The asadmin utility options may precede or follow the subcommand, but asadmin utility options after the subcommand are deprecated.

All asadmin utility options must either precede or follow the subcommand. If asadmin utility options are specified both before and after the subcommand, an error occurs.

Subcommand Options

These options control the behavior of the subcommand, not the asadmin utility. Subcommand options must follow the subcommand.

A subcommand option may have the same name as an asadmin utility option, but the effects of the two options are different.

Options have a long form and a short form.

  • The short form of an option has a single dash (-) followed by a single character.

  • The long form of an option has two dashes (--) followed by an option word.

For example, the short form and the long form of the option for specifying terse output are as follows:

  • Short form: -t

  • Long form: --terse

Most options require argument values, except Boolean options, which toggle to enable or disable a feature.

Operands of asadmin Utility Subcommands

Operands specify the items on which the subcommand is to act. Operands must follow the argument values of subcommand options, and are set off by a space, a tab, or double dashes (--). The asadmin utility treats anything that follows the subcommand options and their values as an operand.

To Run an asadmin Utility Subcommand in Single Mode

In single mode, you must type a separate asadmin command for each subcommand that you want to use. After the subcommand has run, you are returned to the operating system’s command shell. Any asadmin utility options must be specified in each separate asadmin command that you run.

If you require the same asadmin utility options for multiple subcommands, use the asadmin utility in multimode. For more information, see To Start a Multimode Session.

  1. In the operating system’s command shell, run the asadmin utility, specifying the subcommand.

  2. If necessary, also specify any required asadmin utility options, subcommand options, and operands.

Example 2-1 Running an asadmin Utility Subcommand in Single Mode

asadmin list-applications
hello <web>
Command list-applications executed successfully.

This example runs the list-applications subcommand in single mode. In this example, the default values for all options are used.

The example shows that the application hello is deployed on the local host.

Example 2-2 Specifying an asadmin Utility Option With a Subcommand in Single Mode

asadmin --host srvr1.example.com list-applications
basic-ezcomp <web>
scrumtoys <web>
ejb31-war <ejb, web>
automatic-timer-ejb <ejb>
Command list-applications executed successfully.

This example specifies the --host asadmin utility option with the list-applications subcommand in single mode. In this example, the DAS is running on the host srvr1.example.com.

The example shows that the applications basic-ezcomp, scrumtoys, ejb31-war, and automatic-timer-ejb are deployed on the host srvr1.example.com.

Example 2-3 Specifying an asadmin Utility Option and a Subcommand Option in Single Mode

asadmin --host srvr1.example.com list-applications --type web
basic-ezcomp <web>
scrumtoys <web>
ejb31-war <ejb, web>
Command list-applications executed successfully.

This example specifies the --host asadmin utility option and the --type subcommand option with the list-applications subcommand in single mode. In this example, the DAS is running on the host srvr1.example.com and applications of type web are to be listed.

To Display Help Information for the asadmin Utility or a Subcommand

Payara Server provides help information about the syntax, purpose, and options of the asadmin utility and its subcommands.

This help information is also available in the Payara Server Command Reference Manual.

  1. If you are displaying help information for a remote subcommand, ensure that the server is running. Remote subcommands require a running server.

  2. Specify the subcommand of interest as the operand of the help subcommand. If you run the help subcommand without an operand, help information for the asadmin utility is displayed.

Example 2-4 Displaying Help Information for the asadmin Utility

asadmin help

This example displays the help information for the asadmin utility.

Example 2-5 Displaying Help Information for an asadmin Utility Subcommand

asadmin help create-jdbc-resource

This example displays the help information for the create-jdbc-resource subcommand.

To display the available subcommands, use the list-commands subcommand. Local subcommands are displayed before remote subcommands. If the server is not running, only local subcommands are displayed.

To Start a Multimode Session

The asadmin utility can be used in multiple command mode, or multimode. In multimode, you run the asadmin utility once to start a multimode session.During the session, the asadmin utility continues to accept subcommands until you end the session and return to the operating system’s command shell.

Any asadmin utility options that you set for your multimode session are used for all subsequent subcommands in the session.

Starting a multimode session does not require a running DAS.

  1. Do one of the following:

    • Run the asadmin utility without a subcommand.

    • Use the multimode subcommand.

  2. If necessary, also specify any asadmin utility options that will apply throughout the multimode session.

  3. In a multimode session, the asadmin> prompt is displayed on the command line. You can now type asadmin subcommands at this prompt to administer Payara Server.

Example 2-6 Starting a Multimode Session With asadmin Utility Options

asadmin --user admin1 --passwordfile pwd.txt multimode

This example starts a multimode session in which the asadmin utility options --user and --passwordfile are set for the session.

Example 2-7 Starting a Multimode Session by Using the multimode Subcommand

asadmin multimode

This example uses the multimode subcommand to start a multimode session in which the default asadmin utility options are used.

The asadmin> prompt is displayed on the command line.

Example 2-8 Running a Subcommand in a Multimode Session

asadmin
Use "exit" to exit and "help" for online help.

asadmin> list-domains
Name: domain1 Status: Running
Command list-domains executed successfully.
asadmin>

This example starts a multimode session and runs the list-domains subcommand in the session.

Starting a Multimode Session From Within an Existing Multimode Session

You can start a multimode session from within an existing session by running the multimode subcommand from within the existing session. After you end the second multimode session, you return to your original multimode session.

To End a Multimode Session

At the asadmin> prompt, type one of the following commands or key combinations:

  • exit

  • quit

  • UNIX and Linux systems: Ctrl-D

  • Windows systems: Ctrl-Z

Do not type Ctrl-C to end a multimode session. If a domain or Payara Server instance is started from the multimode session, typing Ctrl-C kills the domain or instance process.

You are returned to the operating system’s command shell and the asadmin> prompt is no longer displayed. If the asadmin> prompt is still displayed, you might have opened a multimode session within a multimode session. In this situation, repeat this procedure to end the remaining multimode session.

To enable Multimode Session Event Designators

This feature allows the use of Bash Event Designators when using Payara Server’s Asadmin CLI in multimode.

An Event Designator is a reference to a command line entry in the history list, which makes it easy for users to refer and re-use previous asadmin subcommands entries.

This feature is disabled by default in Payara Server and has to be enabled first before being used.
If this feature is enabled, all occurrences of the \ character will be escaped and thus, removed before running the corresponding command. You’ll have to escape these characters and turn them into \\ for any commands to be properly parsed.

Enabling JLine Event Expansion

To enable support for JLine event designators just set the AS_ADMIN_DISABLE_EVENT_EXPANSION environment variable to false. Follow these steps depending on your operating system:

Linux and *Nix variants

  1. Open the Terminal

  2. Type the following command

    export AS_ADMIN_DISABLE_EVENT_EXPANSION=false

  3. Check that the variable has been correctly set:

    echo $AS_ADMIN_DISABLE_EVENT_EXPANSION
Windows

  1. Open Command Prompt as an Administrator

  2. Type the following commands

    setx AS_ADMIN_DISABLE_EVENT_EXPANSION "false" /m
set AS_ADMIN_DISABLE_EVENT_EXPANSION=false

  3. Check that the variable has been correctly set:

    echo %AS_ADMIN_DISABLE_EVENT_EXPANSION%

To Run a Set of asadmin Subcommands From a File

Running a set of asadmin subcommands from a file enables you to automate repetitive tasks.

  1. Create a plain text file that contains the sequence of subcommands that you want to run.

  2. Run the multimode subcommand, specifying the file that you created.

    If necessary, also specify any asadmin utility options that are required to enable subcommands in the file to run.

Example 2-9 Running a Set of asadmin Subcommands From a File.

create-domain --portbase 9000 customdomain
start-domain customdomain
list-commands
stop-domain customdomain
delete-domain customdomain

This example contains the following:

  • A listing of a file that is named commands_file.txt, which contains a sequence of asadmin subcommands.

  • The command to run the subcommands in the file commands_file.txt

The commands_file.txt file contains the asadmin utility subcommands to perform the following sequence of operations:

  1. Creating the domain customdomain

  2. Starting the domain customdomain

  3. Listing all available subcommands

  4. Stopping the domain customdomain

  5. Deleting the domain customdomain

This example runs the sequence of subcommands in the commands_file.txt file. Because the --portbase option is specified for the create-domain subcommand in the file, the --port asadmin utility option must also be set.

asadmin --port 9048 multimode --file commands_file.txt

For more information about the subcommands in the preceding example, see the following help pages:

To Run asadmin Subcommands in --detach Mode

You can use the --detach option of the asadmin utility to detach asadmin subcommands and run them in the background in detach mode. The asadmin --detach option is useful for long-running subcommands and enables you to run several independent subcommands from one console or script.

  1. Ensure that the server is running. Remote commands require a running server.

  2. Detach and run the subcommand by using the asadmin --detach option.

Example 2-10 Using the --detach Option in Single Mode

asadmin --detach create-cluster Cluster1
Job ID: 1
Command create-cluster started successfully.

This example uses the asadmin --detach option in single mode to run the create-cluster subcommand.

Example 2-11 Using the --detach Option in Multimode

asadmin> create-cluster Cluster1 --detach
Job ID: 1
Command create-cluster started successfully.

This example uses the asadmin --detach option in multimode to run the create-cluster subcommand.

Job IDs are assigned to subcommands that are started using the asadmin --detach option or that contain progress information. You can use the list-jobs subcommand to list jobs and their job IDs, the attach subcommand to reattach to a job and view its status, and the configure-managed-jobs subcommand to configure how long information about jobs is kept.

Example 2-12 Listing Jobs

asadmin> list-jobs
JOB ID     COMMAND           STATE       EXIT CODE TIME OF COMPLETION
1          create-instance    COMPLETED   SUCCESS   2023-02-15 16:16:16 PST
2          deploy            COMPLETED   FAILURE   2023-02-15 18:26:30 PST
Command list-jobs executed successfully

This example runs the list-jobs subcommand in multimode to list jobs and job information.

Example 2-13 Attaching to a Subcommand and Checking Its Status

asadmin> attach 1
Command create-cluster executed with status SUCCESS.
Command attach executed successfully.

This example runs the attach subcommand in multimode to attach to the create-cluster subcommand with a job ID of 1. If a subcommand is still in progress, the output displays the current status, such as percentage complete.

Example 2-14 Configuring Managed Jobs

asadmin> configure-managed-jobs --job-retention-period=36h
Command configure-managed-jobs executed successfully.

This example runs the configure-managed-jobs subcommand in multimode to set the job retention period to 36 hours. Time periods can be specified in Hh|Mm|Ss format for hours, minutes, or seconds.

For the full syntax and options of the subcommands in the preceding examples, see the following help pages:

Administering System Properties

Shared server instances will often need to override attributes defined in their referenced configuration. Any configuration attribute can be overridden through a system property of the corresponding name.

To Create System Properties

Use the create-system-properties subcommand in remote mode to create or update one or more system properties of the domain or configuration. Any configuration attribute can be overwritten through a system property of the corresponding name.

  1. Ensure that the server is running. Remote subcommands require a running server.

  2. Create system properties by using the create-system-properties subcommand.

Example 2-15 Creating a System Property

asadmin> create-system-properties http-listener-port=1088
Command create-system-properties executed successfully.

This example creates a system property associated with http-listener-port=1088 on localhost.

To List System Properties

Use the list-system-properties subcommand in remote mode to list the system properties that apply to a domain, cluster, or server instance or configuration.

  1. Ensure that the server is running. Remote subcommands require a running server.

  2. List system properties by using the list-system-properties subcommand.

The existing system properties are displayed, including predefined properties such as HTTP_LISTENER_PORT and HTTP_SSL_LISTENER_PORT.

Example 2-16 Listing System Properties

asadmin> list-system-properties
http-listener-port=1088
Command list-system-properties executed successfully.

This example lists the system properties on host localhost.

To Delete a System Property

Use the delete-system-property subcommand in remote mode to delete system properties.

  1. Ensure that the server is running. Remote subcommands require a running server.

  2. List the existing system properties by using the list-system-properties subcommand.

  3. Delete the system property by using the delete-system-property subcommand.

  4. If necessary, notify users that the system property has been deleted.

Example 2-17 Deleting a System Property

asadmin> delete-system-property http-listener-port
Command delete-system-property executed successfully.

This example deletes a system property named http-listener-port from localhost.

System Properties Inventory

The following properties are used exclusively by Payara Server to configure specific settings across multiple features:

fish.payara.clientHttpsProtocol

Sets the TLS version to be used by the asadmin client.

This is separate from the TLS version set for HTTPS communication on a listener.

Valid values are:

  • TLSv1.2,

  • TLSv1.3

  • TLSv1.3 (default)

fish.payara.classloading.delegate

When set to false, libraries from applications, and domain-dir/lib will override the library in the as-install/glassfish/modules directory

Defaults to true.

fish.payara.admin.command.jline.log.disable

When set to true, JLine logging entries for invalid key bindings and other unwanted errors will be prevented

This is a property used exclusively by the Asadmin CLI

Defaults to false

fish.payara.deployment.transform.namespace

When set to true, namespace transformation (javax.* to jakarta.\* package refactoring) is always performed.

If the value is undefined then auto transformation is performed on the absence of jakarta.\* classes in the deployment archive otherwise transformation task is disabled.

Defaults to null (undefined)

fish.payara.permittedFormBasedAuthHttpMethods

A comma separated list of HTTP methods that are permitted to use for FORM based authentication (j_security_check).

If not set all HTTP methods are permitted.

Valid values are:

  • GET

  • HEAD

  • POST

  • PUT

  • DELETE

  • CONNECT

  • OPTIONS

  • TRACE

  • PATCH

    Defaults to null (undefined)

fish.payara.shutdowngrace

After server shutdown is initiated the server waits this period of time (in seconds) to finish ongoing requests before terminating.

New requests are still accepted during this grace period. Accepts values between 0 - Integer.MAX and defaults to 0.

fish.payara.SO_KEEPALIVE

Enables keep alive (SO_KEEPALIVE) on the sockets created by an IIOP listener. Can be set as a global system property, or as a property on a specific listener (with the latter taking precedence over the global setting if both are set).

Replaces deprecated property fish.payara.SOKeepAlive.

Defaults to false

org.glassfish.grizzly.DEFAULT_MEMORY_MANAGER

If option (defined as JVM Option with -D or as System Property value) org.glassfish.grizzly.DEFAULT_MEMORY_MANAGER is not present in the server/instance configuration, the server will override the Grizzly default and use the HeapMemoryManager class.

To override this behaviour (so to use a different memory manager), you must specify this JVM option in the server/instance config with your desired setting.

Valid values are:

  • org.glassfish.grizzly.memory.HeapMemoryManager (default)

  • org.glassfish.grizzly.memory.PooledMemoryManager

  • org.glassfish.grizzly.memory.ByteBufferManager

deployment.resource.validation

This option (defined as JVM Option with -D or as System Property value) defines if the resources are validated during deployment of the application.

When active, the default value, all JNDI references are verified but those references can be provided by the application itself and thus not yet available at deployment time (for example the java:module/env/ based ones).

By setting this option to false, validation is not performed and deployment will succeed.

However, issues will occur at runtime of the application in case of errors in the references.

Defaults to true

fish.payara.javax.servlet.jsp.disable-static-field-references

This option brings back the behaviour of evaluating EL in JSP pages from previous iterations.

When enabled, a static field reference won’t be evaluated.

Defaults to false

fish.payara.node.ssh.timeout

This option sets the SSH timeout in milliseconds for running commands on SSH nodes.

This is a separate timeout to the Asadmin CLI communication or any command specific timeout, this is specifically for the SSH connection used for running certain commands that operate on the remote node itself (e.g. setup-ssh and start-instance).

If set to an invalid value a warning will be logged and the default will be used.

Accepts values from 1 - Integer.MAX. Defaults to 120000ms

fish.payara.tenantcontrol.blocking.disable

This option determines if a server instance should skip its standard checks for if it is available for a Hazelcast Tenantable object.

Defaults to true.

fish.payara.autoscale.maxscale

This option sets the default maximum boundary for the number of instances to scale up or down by when using auto-scale groups.

Accepts values from 1 - Integer.MAX. Defaults to 100 instances.

hazelcast.cp-subsystem.auto-promote

When the Payara Server’s Data Grid/Hazelcast CP subsystem is enabled (more than 0 members are configured), this option will enable or disable an auto-promote behaviour that will allow other server instances to join the Hazelcast CP subsystem when detected by the DAS.

The CP subsystem is automatically enabled on the Data Grid/Hazelcast when the hazelcast.cp-subsystem.cp-member-count system property is set an integer greater than zero.

Defaults to true

hazelcast.auto-partition-group

Enables/disables Hazelcast group auto-partitioning behaviour in Payara Server’s Data Grid.

When auto-partitioning is turned on, instances that join the Data Grid will not follow the default partition group configuration strategy and instead will form individual partition groups. Read more about how partition groups work in the official Hazelcast Platform documentation.

This option is intended to make member partitioning work consistently for highly dynamic environments (like Kubernetes).

Use this option with extreme care

Using Configuration Modularity

With configuration modularity in Payara Server, new modules can be added to Payara Server distributions without modifying the global domain.xml configuration file. Default configuration data for modules is stored in the modules themselves, rather than in domain.xml, and loaded when needed.

Module configuration elements are stored in domain.xml only when the default configuration included in the module is changed or when module configuration elements are added to domain.xml using the create-module-config subcommand. The delete-module-config subcommand removes module configuration elements from domain.xml, and the get-active-module-config subcommand displays the current active configuration of a module.

To Add the Default Configuration of a Module to domain.xml

Use the create-module-config subcommand to add the default configuration of a module to domain.xml.

  1. Ensure that the server is running. Remote subcommands require a running server.

  2. Add the default configuration of a module to domain.xml by using create-module-config subcommand.

Example 2-18 Adding Module Configuration to domain.xml

asadmin> create-module-config web-container
Command create-module-config executed successfully.

This example adds the default configuration of the web container module to domain1 in server-config (the default configuration). Use the --dryrun option to preview the configuration before it is added.

To Remove the Configuration of a Module From domain.xml

Use the delete-module-config subcommand to remove the configuration of a module from domain.xml and cause the module to use the default configuration included in the module.

  1. Ensure that the server is running. Remote subcommands require a running server.

  2. Remove the configuration of a module from domain.xml by using the delete-module-config subcommand.

Example 2-19 Removing Module Configuration From domain.xml

asadmin> delete-module-config web-container
Command delete-module-config executed successfully.

This example deletes the configuration of the web container module from domain1 in server-config (the default configuration).

To Display the Current Active Configuration of a Module

Use the get-active-module-config subcommand to display the current active configuration of a module.

  1. Ensure that the server is running. Remote subcommands require a running server.

  2. Display the current active configuration of a module by using the get-active-module-config subcommand.

Example 2-20 Displaying the Current Active Configuration of a Module

asadmin> get-active-module-config jms-service
At location: domain/configs/config[server-config]
<jms-service default-jms-host="default_JMS_host" type="EMBEDDED"
  <jms-host port="7676" host="localhost" name="default_JMS_host"/>
</jms-service>
Command get-active-module-config executed successfully.

This example displays the current active configuration of the JMS service in server-config (the default configuration).

Administering Resources

This section contains instructions for integrating resources into the Payara Server environment.Information about administering specific resources, such as JDBC, is contained in other chapters.

To Add Resources From an XML File

Use the add-resources subcommand in remote mode to create the resources named in the specified XML file. The following resources are supported: JDBC connection pool and resource, JMS, JNDI, and JavaMail resources, custom resource, connector resource and work security map, admin object, and resource adapter configuration.

The XML file must reside in the domain-dir/config directory. If you specify a relative path or simply provide the name of the XML file, this subcommand will prepend domain-dir/config to this operand.

  1. Ensure that the server is running. Remote subcommands require a running server.

  2. Add resources from an XML file by using the add-resources subcommand. Information about properties for the subcommand is included in this help page.

  3. Restart Payara Server. See To Restart a Domain.

Example 2-21 Adding Resources

asadmin> add-resources c:\tmp\resource.xml
Command : JDBC resource jdbc1 created successfully.
Command : JDBC connection pool poolA created successfully.
Command add-resources executed successfully.

This example creates resources using the contents of the resource.xml file on localhost.

Listing Various System Elements

To Display the Payara Server Version

Use the version subcommand in remote mode to display information about the Payara Server version for a particular server. If the subcommand cannot communicate with the server by using the specified login (user/password) and target (host/port) information, then the local version is displayed along with a warning message.

  1. Ensure that the server is running. Remote subcommands require a running server.

  2. Display the version by using the version subcommand.

Example 2-22 Displaying Version Information

asadmin> version
Version = Payara Server 7.2024.1.Alpha3 #badassfish (build 00)
Command version executed successfully.

This example displays the version of Payara Server on the local host.

To List Applications

Use the list-applications subcommand in remote mode to list the deployed applications. If the --type option is not specified, all applications are listed.

  1. Ensure that the server is running. Remote subcommands require a running server.

  2. List applications by using the list-applications subcommand.

Example 2-23 Listing Applications

asadmin> list-applications --type web
hellojsp <web>
Command list-applications executed successfully.

This example lists the web applications on localhost.

To List Containers

Use the list-containers subcommand in remote mode to list application containers.

  1. Ensure that the server is running. Remote subcommands require a running server.

  2. List containers by using the list-containers subcommand.

Example 2-24 Listing Containers

asadmin> list-containers
List all known application containers

faulttolerance
metrics
appclient
jpa
jpa
osgi
connector
grizzly
health
jwtauth
ejb
openapi
webservices
security
payara-resources_ear
payara-resources
resources_ear
resources
web
ear
cdi
cdi
config
Command list-containers executed successfully.

This example lists the containers on localhost.

To List Modules

Use the list-modules subcommand in remote mode to list the modules that are accessible to the Payara Server module subsystem. The status of each module is included. Possible statuses include NEW and READY.

  1. Ensure that the server is running. Remote subcommands require a running server.

  2. List modules by using the list-modules subcommand.

Example 2-25 Listing Modules

asadmin> list-modules

This example lists the accessible modules.

Information similar to the following is displayed (partial output):

List Of Modules
Module Status Report Begins
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.admin.gf-restadmin-connector [114]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-appserver-modules.microprofile-config-extensions [273]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.transaction.internal-api [389]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.payara-modules.hazelcast-bootstrap [137]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-appserver-modules.hazelcast-eclipselink-coordination [138]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.monitoring-console.core [296]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.ejb.ejb-container [89]], State = [READY]
OSGiModuleImpl:: Bundle = [org.glassfish.corba.glassfish-corba-orb [123]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.core.jakartaee-kernel [203]], State = [READY]
OSGiModuleImpl:: Bundle = [org.apache.felix.shell [430]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-appserver-modules.jmx-monitoring [248]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.security.ssl-impl [383]], State = [READY]
OSGiModuleImpl:: Bundle = [org.glassfish.hk2.osgi-resource-locator [1]], State = [READY]
OSGiModuleImpl:: Bundle = [org.eclipse.angus.mail [10]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-appserver-modules.microprofile-fault-tolerance [279]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.extensions.notifiers.slack-notifier-core [371]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.extensions.notifiers.snmp-notifier-core [379]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-modules.phonehome-bootstrap [347]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-appserver-modules.microprofile-metrics [285]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.jdbc.runtime [216]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.flashlight.framework [105]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-modules.notification-cdi-eventbus-core [302]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.extensions.notifiers.teams-notifier-core [387]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.ejb.http-admin [91]], State = [READY]
OSGiModuleImpl:: Bundle = [org.objectweb.asm.tree.analysis [21]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.orb.enabler [313]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.appclient.server.appclient-connector [16]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-modules.microprofile-config-service [274]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.persistence.gf-jpa-connector [112]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.nucleus.logging [267]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-modules.asadmin-recorder [20]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.osgi-platforms.osgi-container [329]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.concurrent.impl [49]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.admin.cli [4]], State = [READY]
OSGiModuleImpl:: Bundle = [org.apache.felix.configadmin [423]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.nucleus.kernel [262]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.payara-modules.healthcheck-core [142]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.connectors.internal-api [54]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.orb.iiop [314]], State = [READY]
OSGiModuleImpl:: Bundle = [org.glassfish.hk2.api [149]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.persistence.cmp.support-ejb [44]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.jms.core [244]], State = [READY]
OSGiModuleImpl:: Bundle = [org.apache.felix.gogo.shell [428]], State = [READY]
OSGiModuleImpl:: Bundle = [org.objectweb.asm.tree [23]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-appserver-modules.notification-jms-core [305]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-modules.notification-eventbus-core [304]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.concurrent.connector [48]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.connectors.gf-connectors-connector [108]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.grizzly.glassfish-grizzly-extra-all [126]], State = [READY]
OSGiModuleImpl:: Bundle = [org.apache.felix.eventadmin [424]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-appserver-modules.healthcheck-checker [141]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.deployment.autodeploy [77]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.jms.gf-jms-connector [110]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.common.amx-core [7]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-appserver-modules.environment-warning [98]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.admin.config-api [50]], State = [READY]
OSGiModuleImpl:: Bundle = [org.apache.felix.scr [429]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.common.internal-api [157]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-appserver-modules.microprofile-healthcheck [281]], State = [READY]
OSGiModuleImpl:: Bundle = [org.apache.felix.gogo.command [426]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.common.glassfish-mbeanserver [128]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.security.services [367]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.deployment.dol [87]], State = [READY]
OSGiModuleImpl:: Bundle = [org.glassfish.hk2.runlevel [154]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.connectors.runtime [55]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.admin.monitoring-core [298]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.security.ejb.security [94]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.extensions.notifiers.datadog-notifier-core [73]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.web.weld-integration [416]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.payara-modules.opentracing-adapter [309]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.payara-modules.healthcheck-stuck [146]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.admin.util [6]], State = [READY]
OSGiModuleImpl:: Bundle = [org.objectweb.asm [25]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-appserver-modules.microprofile-jwt-auth [283]], State = [READY]
OSGiModuleImpl:: Bundle = [org.glassfish.hk2.utils [155]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.security.appclient.security [18]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.ejb.opentracing [93]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.web.naming [407]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.common.glassfish-naming [129]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.nucleus.glassfish [131]], State = [READY]
OSGiModuleImpl:: Bundle = [org.objectweb.asm.commons [22]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.hk2.config [150]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.ejb.gf-ejb-connector [109]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.jdbc.config [215]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.security.jacc.provider.inmemory [160]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.resourcebase.resources.nucleus-resources [307]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.payara-modules.requesttracing-core [352]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-appserver-modules.microprofile-openapi [287]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.resources.javamail-connector [206]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.transaction.jts [258]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.webservices.jsr109-impl [255]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.common.util [47]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.webservices.connector [411]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.common.glassfish-api [117]], State = [READY]
OSGiModuleImpl:: Bundle = [jakarta.inject.jakarta.inject-api [181]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-modules.asadmin-audit [19]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.admingui.gf-admingui-connector [106]], State = [READY]
OSGiModuleImpl:: Bundle = [org.glassfish.hk2.locator [153]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.extensions.notifiers.newrelic-notifier-core [300]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.grizzly.nucleus-grizzly-all [306]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-appserver-modules.healthcheck-metrics [144]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.admin.rest-service [359]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.security [368]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.deployment.javaee-core [80]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.security.ee [366]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.resources.connector [353]], State = [READY]
OSGiModuleImpl:: Bundle = [org.glassfish.hk2.class-model [34]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.web.gf-web-connector [115]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-modules.notification-core [303]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.deployment.javaee-full [81]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.payara-modules.payara-executor-service [333]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.ha.hazelcast-store [136]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.web.cli [401]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-appserver-modules.payara-micro-service [339]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.transaction.jta [257]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-modules.healthcheck-cpool [143]], State = [READY]
OSGiModuleImpl:: Bundle = [org.glassfish.hk2.osgi-adapter [327]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.load-balancer.gf-load-balancer-connector [113]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-appserver-modules.rest-monitoring-service [358]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.batch.glassfish-batch-connector [119]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.web.gf-weld-connector [116]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.payara-appserver-modules.microprofile-config [275]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.deployment.common [79]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.extensions.notifiers.xmpp-notifier-core [421]], State = [READY]
OSGiModuleImpl:: Bundle = [org.apache.felix.fileinstall [425]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.hk2.config-types [51]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.orb.connector [312]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.internal.docker [86]], State = [READY]
OSGiModuleImpl:: Bundle = [org.apache.felix.gogo.runtime [427]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.extensions.notifiers.email-notifier-core [96]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.server.core.common.container-common [71]], State = [READY]
OSGiModuleImpl:: Bundle = [org.objectweb.asm.util [24]], State = [READY]
OSGiModuleImpl:: Bundle = [fish.payara.extensions.notifiers.discord-notifier-core [85]], State = [READY]

...
Command list-modules executed successfully.

To List Subcommands

Use the list-commands subcommand in remote mode to list the deployed asadmin subcommands. You can specify that only remote subcommands or only local subcommands are listed. By default, this subcommand displays a list of local subcommands followed by a list of remote subcommands.

  1. Ensure that the server is running. Remote subcommands require a running server.

  2. List subcommands by using the list-commands subcommand.

Example 2-26 Listing Subcommands

asadmin> list-commands --localonly
create-domain
delete-domain
list-commands
list-domains
login
monitor
start-database
start-domain
stop-domain
stop-database
version
Command list-commands executed successfully.

This example lists only local subcommands.

To List Timers

The timer service is a persistent and transactional notification service that is provided by the enterprise bean container and is used to schedule notifications or events used by enterprise beans. All enterprise beans except stateful session beans can receive notifications from the timer service.

Persistent timers set by the service are not destroyed when the server is shut down or restarted.

Use the list-timers subcommand in remote mode to list the persistent timers owned by a specific server instance. You can use this information to decide whether to do a timer migration, or to verify that a migration has been completed successfully.

  1. Ensure that the server is running. Remote subcommands require a running server.

  2. List timers by using the list-timers subcommand.

Example 2-27 Listing Timers

asadmin> list-timers server
1
The list-timers command was executed successfully.

This example lists the timers in a particular standalone server instance. There is one currently active timer set.

To Show Component Status

Use the show-component-status subcommand in remote mode to get the status (either enabled or disabled) of the specified deployed component.

  1. Ensure that the server is running. Remote subcommands require a running server.

  2. Show component status by using the show-component-status subcommand.

Example 2-28 Showing Status of a Component

asadmin> show-component-status MEjbApp
Status of MEjbApp is enabled
Command show-component-status executed successfully.

This example shows the status of the MEjbApp component.

The implementation of the Payara Server REST interfaces is based on project Jersey. Project Jersey is the reference implementation of Jakarta RESTful Web Services.

See Also