AMX: Design and Use

by Lloyd L Chambers
Last updated: 01 August 2006

Contents

1. Introduction

2. Design
    Design goals 
        Ease of use
        Consistency in data types, behavior and idioms
        Use of standard data types
        MBeans and Client Proxies
        Structural consistency
    AMX interfaces and structural overview 
        Groups of AMX MBeans
        The Base AMX interface
        The Container interface
        The AMXConfig interface
        The Monitoring and MonitoringStats interfaces
        The J2EEManagedObject interface
        The Extra interface
        Utility and manager MBeans 
        Helper classes 
        Dotted name support 
    Exceptions
    Notifications
    Complex data types
	
3. Using AMX
    Connecting to the Domain Admin Server (DAS)
    Navigating through the AMX hierarchy

Appendix A —Sample AMX Hierarchy 

1. Introduction

This document provides an overview of the Glassfish AppServer Management Extensions (AMX) management API design. For developers interested in making changes to the source code, please see AMX: Implementation.

AMX was first introduced in Sun Java System AppServer 8.1, the Platform Edition of which is known as Glassfish. AMX is implemented in pure Java using the Java Management Extensions (JMX) technology. Familiarity with JMX is helpful in understanding how AMX works, but most of AMX can also be used with no knowledge of JMX.

Glossary
AMX

AppServer Management EXtensions. The terms “AppServer” and “Management” should be self-explanatory. The term “Extensions” refers to the addition of a considerable number of interfaces beyond the basic structure defined by the J2EE Management specification (JSR 77). [See also the Glassfish JSR 77 page).

AMX is composed of several hundred Java interfaces (eg “public interface DomainRoot {...} ). Each of this interfaces represents the runtime capabilities of a server-side JMX MBean residing in the AppServer. See also AMX Dynamic Proxy.

JMX
JMX Remote
Java Management Extensions (JSR 3) and remote access (JSR 160).
Glassfish The name for Sun's open source J2EE implementation, of which AMX is a part.
AMX Dynamic Client Proxy

The J2SE java.lang.reflect.proxy API is used to generate Java objects which implement the various AMX interfaces. Each proxy internally stores the JMX ObjectName of a server-side JMX MBean whose MBeanInfo corresponds to the AMX interface implemented by the proxy.

In this document, the term Client Proxy is used to mean AMX Dynamic Client Proxy.

2. Design

2.1 Design goals

AMX was designed with several key principles in mind:

  • ease of use;
  • consistency in data types, behavior, and idioms;
  • use of standard data types whenever possible;
  • accessible as both standard JMX MBeans through an MBeanServerConnection, and/or through Dynamic Client Proxies.
  • structural consistency with both the domain.xml configuration file and with the J2EE Management model.

Close attention to those design goals has resulted in an API which is very predictable in its structure and details. Understanding the design goals in detail will aid the user in understanding what to expect in AMX.

2.1.1 Ease of use

Ease of use is addressed in multiple ways—

The use of Dynamic Client Proxies which implement the various AMX interfaces makes accessing the server-side MBeans as simple as using local objects. No knowledge of JMX is needed, nor is any awareness of remote access necessary; all Client Proxies can be used just like any other local Java object.

The well-defined containment hierarchy [sample] of the AMX MBeans is reflected directly in the AMX interfaces. All AMX interfaces which logically contain other AMX interfaces provide both generic methods (via the Container interface) and explicit methods to obtain other AMX objects logically contained with themselves (containees). Every containee also has a getContainer() method. Thus, it is possible to navigate the AMX MBean hierarchy via explicit methods.

The ObjectName for each AMX MBean follows a formal naming convention that mirrors the containment hierarchy. Thus, the containment hierarchy is made explicit in the ObjectNames of AMX MBeans and can itself be used for navigation and query purposes.

Routines that simplify finding desired MBeans are provided in the QueryMgr, removing the need to understand JMX in order to find desired MBeans. This is particularly important when working with Client Proxies; it helps maintain a level of abstraction over JMX by eliminating the need to deal with ObjectNames returned from queries.

For programmers making more extensive use of AMX, particularly advanced users who may use more JMX facilities, a considerable amount of utility code is included in the AMX APIs in the com.sun.appserv.management.util.* packages.

2.1.2 Consistency in data types, behavior and idioms

Great care was taken with the following:

  • structured naming conventions for class, method, attribute and constant names;
  • similar approach for all create() and remove methods;
  • all access to MBean Attributes follows the same get/set idiom in each AMX interface;
  • all AMX-issued JMX Notifications have the same structure;
  • avoidance of magic values/numbers for parameters or return types;
  • explicit parameters (where possible) allow for for compile-time correctness checking.

2.1.3 Use of standard data types

Wherever feasible, standard data types were used, up to and including the use of java.util.Map to encode more complex data types. This approach was taken to avoid requiring a proprietary client jar for pure-JMX clients, but has the additional benefit of avoiding incompatibilities between releases. Helper routines are always provided to convert such Maps into the corresponding AMX data type (for those clients using the AMX interfaces). It also has the side benefit of backward and forward compatibility.

With the release of AppServer 9.0 AMX was enhanced to support complex data types for clients using AMX Dynamic Client Proxies, while leaving the over-the-wire use of java.util.Map in place for such data types. See Complex Data Types.

2.1.4 MBeans and Client Proxies

All AMX management interfaces ultimately correspond to JMX MBeans residing in the AppServer. For some clients, a pure-JMX approach with an MBeanServerConnection and ObjectName is desirable.

However, for most programming tasks, use of Client Proxies greatly simplifies using AMX, while also providing strong type-checking at compile time. Code written using client proxies can be considerably simpler and easier to understand than code using JMX directly.

2.1.5 Structural consistency

Nearly all of the AppServer configuration is stored in domain.xml, which, like all XML files, has a formal containment structure. AMX represents all elements of domain.xml as interfaces in the com.sun.appserv.management.config package. Those interfaces model the formal containment structure found in domain.xml. Thus, anyone familiar with domain.xml should be immediately comfortable with the AMX configuration interfaces, because the names of the AMX interfaces are the same (or nearly so) as the names of the XML elements and Attributes found in domain.xml.

AMX also mirrors the J2EE Management (JSR 77) structure, including its j2eeTypes within the overall AMX hierarchy and also leveraging the j2eeType property within the ObjectName of every AMX MBean. Thus, anyone familiar with JSR 77 will recognized those types within the AMX hierarchy (see com.sun.appserv.management.j2ee).

2.2 AMX interfaces and structural overview

This section discusses the various AMX interfaces and related matters. Each AMX interface corresponds to zero or more runtime instances of JMX MBeans in the server.

In this discussion, the term AMX object means either/or the AMX Client Dynamic Proxy and its corresponding JMX MBean. An AMX object is distinct from an AMX interface in that it refers to a instantiated instance of an AMX interface; there may or may not be instances of a particular AMX interface in existence at any given point in time, depending on configuration and monitoring status of the server.

AMX uses consistent naming conventions for its interfaces. The conventions are documented in the javadoc for com.sun.appserv.management.

2.2.1 Groups of AMX MBeans

All AMX MBeans expose a Group attribute, available as the getGroup() method in each AMX interface. The group values are the following:

The meaning should be relatively self-evident; click on each link to see the javadoc. The GROUP_CONFIGURATION, GROUP_MONITORING and GROUP_JSR77 MBeans all define their own containment hierarchies. The GROUP_UTILITY and GROUP_OTHER MBeans are typically singleton MBeans with dedicated purposes, such as the QueryMgr, BulkAccess and DeploymentMgr.

2.2.2 The base AMX interface

The AMX interface is the base interface which is extended by all other AMX interfaces. Some key attributes (methods) are explained here.

Method
Comments
getName() The name of the AMX object, which is the same as the name property of its ObjectName.
getJ2EEType()

The j2eeType of the AMX object, which is the same as the j2eeType property of its ObjectName. Every AMX MBean has a distinct type, known as the j2eeType (this concept is derived from the JSR77 spec). All AMX objects with the same j2eeType have the same interface; they are distinct instances of the same interface.

getContainer() Returns the containing AMX object. All AMX objects have a Container except for DomainRoot.
getDomainRoot() DomainRoot is the Container for all other AMX objects.
getFullType() A string representing the j2eeTypes of the containment hierarchy for this object.

Example:
J2EEServer.J2EEApplication.WebModule.Servlet

For this example, a Servlet is contained within a WebModule, which is contained within a J2EEApplication, which is contained within a J2EEServer. J2EEServer is implicitly contained within a J2EEDomain, which is contained by DomainRoot.

getGroup()

The group to which this AMX object belongs. See Groups of AMX MBeans.

2.2.3 The Container interface

The Container interface is implemented by all AMX objects which logically contain other AMX objects. It methods are essentially a form of localized query which restricts its results to the AMX object(s) logically contained directly within the Container (non-recursive) . Some containees potentially exist, but may or may not actually be present. For example, optional configuration elements may or may not exist in domain.xml, and thus their corresponding AMX objects will be null until that configuration is created.

You can find the Container for any AMX object by calling getContainer(). The only AMX object without a Container is DomainRoot; its Container is null.

Please see the javadoc for details on the methods.

2.2.4 The AMXConfig interface

All AMX interfaces that represent configuration extend from AMXConfig, and are arranged in a hierarchy under DomainConfig. These MBeans are all in the group GROUP_CONFIGURATION. Many AMXConfig extend Container, analagous to the elements in domain.xml that contain other elements.

The AMXConfig interface defines JMX Notifications emitted by AMX configuration MBeans. Please see the javadoc for details.

2.2.5 The Monitoring and MonitoringStats interface

AMX interfaces that support monitoring extend Monitoring, and are arranged in a hierarchy under MonitoringRoot. These MBeans are all in the group GROUP_MONITORING.

MBeans that provide Stats implement the MonitoringStats interface, which extends Monitoring.

2.2.6 The J2EEManagedObject interface

AMX interfaces represent a J2EE Management object extend from J2EEManagedObject, and are arranged in a hierarchy under J2EEDomain. These MBeans are all in the group GROUP_JSR77.

Some J2EEManagedObject instances provide the navigational routines getConfigPeer() and getMonitoringPeer(), useful for getting to corresponding configuration or monitoring objects. See the javadoc for details.

2.2.7 The Extra interface

The Extra interface, which extends StdAttributesAccess, allows access to JMX features directly, starting with any AMX object. Those wishing to combine the ease of use of AMX Dynamic Client proxies with the generic functionality of JMX can use Extra to access it.

For example, you might want to get the MBeanServerConnection from an AMX:

final MBeanServerConnection conn =
Util.getExtra( amx ).getConnectionSource().getMBeanServerConnection();

There are also convenience routines such as getAllAttributes(), getAttributeNames(), etc.

2.2.8 Utility and manager MBeans

There are a number of utility MBeans that AMX offers noted in the table below. These MBeans all extend either or both of the Utility and Singleton interfaces.

Interface Comments
SystemInfo Provides queries for determining AppServer capabilities, such as whether clustering is supported.
QueryMgr Provides JMX-like queries which are restricted to AMX MBeans.
BulkAccess Provides network-efficient “bulk” calls whereby many Attributes/Operations in many MBeans may be fetched/invoked in one invocation, thus minimizing network overhead.
NotificationService Provides buffering and selective dynamic listening for Notifications on AMX MBeans.
UploadDownloadMgr Supports uploading and downloading of files to/from the AppServer.
DeploymentMgr

Supports deployment of J2EE applications and modules.

Note: com.sun.appserv.management.deploy.DeploymentMgr will be deprecated in Glassfish 9.1. Use the JSR88 DeploymentManager as an alternative.

2.2.9 Helper classes

AMX offers a number of classes that simplify certain operations, such as connecting to the server, uploading a file or finding references to to deployed items. These helper classes may all be found in the package com.sun.appserv.management.helper.

Unlike AMX interfaces, the helper package contains concrete classes that use the functionality provided by AMX interfaces.

2.2.10 Dotted name support

Consistent with the dotted names offered by the AppServer 'asadmin' command line interface, AMX offers the ConfigDottedNames and MonitoringDottedNames interfaces.

AMX exposes each of the dotted names as a JMX Attribute. Unlike most AMX interfaces, dotted names are accessed generically, because the available dotted names can vary dynamically, and the number of distinct names may be quite large. See the javadoc for details.

2.3 Exceptions

Exceptions are an awkward problem for several reasons:

In either case, determining the original Exception (or Throwable) might require finding the original cause because the JMX MBeanServer will wrap most exceptions in an MBeanException. For this reason, AMX provides the utility ExceptionUtil.getRootCause().

There are two cases to distinguish:

1.  Direct use of JMX via MBeanServerConnection.  In this case, the exceptions that get thrown are defined by the MBeanServerConnection methods—5-7 different exceptions for invoke(), getAttribute(), etc.

Example—assume you want to get an Attribute named “Classpath” using MBeanServerConnection:

try {
    String classpath = conn.getAttribute( objectName, “Classpath” );
} catch( Exception e ) {
// catch MBeanException, AttributeNotFoundException,
InstanceNotFoundException, ReflectionException, IOException
    Throwable t   = ExceptionUtil.getRootCause(e);
}


2.  Use of AMX client proxies.  In this case, any Exception thrown gets wrapped by java.lang.reflect.Proxy with an UndeclaredThrowableException.

Example—assume you want to get an Attribute named “Classpath” using an AMX interface:

try {
    String classpath = amx.getClasspath();
} catch( UndeclaredThrowableException e ) {
    Throwable t   = ExceptionUtil.getRootCause(e);
}


Either case requires the same logic.  In the MBeanServerConnection case, you can catch the 5 types separately, but that's just as easily done using logic after catching the UndeclaredThrowableException.  Note that in both cases, it can be a chain of Throwables, and thus Throwable.getCause() is not sufficient; for this reason AMX includes the utility routine ExceptionUtil.getRootCause().

Even if the AMX API declared all its exceptions (which it can't, given that internal implementation changes could introduce new exceptions and remove others), you would still have to extract such Exceptions from an MBeanException (eg call ExceptionUtil.getRootCause()).

2.4 Notifications

JMX defines certain standard Notifications, including the base Notification and certain others which extend it, such as AttributeChangeNotification, MBeanServerNotification, etc.

AMX does not introduce any new proprietary Notifications, but instead uses the base Notification for all Notifications it emits (other than standard ones). AMX uses the UserData field to store a java.util.Map. The contents of this map, and the keys into it, are defined in each AMX interface that issues Notification(s). For examples, please see DeploymentMgr and LogRecordEmitter.

AMX provides utility routines in com.sun.appserv.management.Util to access the Map in the UserData field:

Map<String,Serializable> getAMXNotificationData( Notification notif );

Serializable getAMXNotificationValue( Notification notif, String key );

<T extends Serializable> T getAMXNotificationValue( Notification notif, String key, Class<T> theClass);

Use of these routines is preferred for future compatibility.

AMX also provides some advanced capabilities for listening for Notifications and for buffering them to avoid losing them. Please see NotificationServiceMgr and NotificationEmitterService.

2.5 Complex data types

In AppServer 9.0 AMX was enhanced to support complex data types with AMX Dynamic Client Proxies, while leaving the use of java.util.Map in place for transporting such data types "over the wire". Thus, over-the-wire generic access is preserved, but a client using the AMX interfaces automatically enjoys use of the appropriate interface, without having to concern itself with converting a java.util.Map to the appropriate type.

The following methods are examples of this increase in usability:

WebServiceEndpointInfo getWebServiceEndpointInfo(...); // WebServiceMgr
MessageTrace[] getMessagesInHistory(); // WebServiceEndpoint
LogQueryResult queryServerLog(...); // Logging:

Prior to AMX 9.0, the methods shown above would have been declared as:

Map<String,Serializable> getWebServiceEndpointInfo(...);
Map<String,Serializable>[] getMessagesInHistory();
List<String,Serializable> queryServerLog(...);

Implementation of this support late in the development cycle did not allow time to update certain AMX interfaces, such as DeploymentMgr.

3. Using AMX

This section contains hints and tips on using AMX. One of the best ways to get started is to run the sample command line, then read the corresponding code to see what AMX facilities are being used. The usage discussed in this section assumes use of AMX Dynamic Client Proxies. If you are using straight JMX through MBeanServerConnection, the steps are similar, at the expense of more coding effort.

3.1 Connecting to the Domain Admin Server (DAS)

The first step in using AMX is to establish a connection to the Domain Admin Server or DAS. The Sample Guide explains how to do this, but two things are worth noting:

  • the port used by AMX is an RMI port (default 8686), not the GUI (http/s) port. Connecting to the GUI port will not work.
  • You will need to know whether TLS (SSL) is enabled or not in order to connect.

3.2 Navigating through the AMX hierarchy

The first step in accessing AMX objects is to obtain DomainRoot, via
AppserverConnectionSource.getDomainRoot(), as detailed in the sample guide.

There are multiple ways to move through the available AMX objects:

  • calling getter method(s) that return other AMX objects or Maps of AMX Objects;
  • querying for objects using the QueryMgr;
  • using Container methods

The sample code shows a number of examples of how this is done.

Appendix A —Sample AMX hierarchy

This hierarchy was generated by running the show-hierarchy command as found in the sample command line interface. Module monitoring levels were set to OFF to avoid too large an example; with monitoring set to HIGH, the monitoring hierarchy expands considerably.

Each line in the listing represents an AMX object (MBean). If there is a non-generic name, it is denoted as j2eeType=name, otherwise only its j2eeType is given, as found in XTypes.

Each level of indentation represents containment within the containing object (see Container), with X-DomainRoot at the root. Excepting the Java EE management classes (defined by JSR 77), the name of an AMX interface is the same as the j2eeType, minus the “X-” prefix.

A sample j2eeType hierarchy from a newly-created AppServer domain:

X-DomainRoot=amx
  X-BulkAccess
  X-ConfigDottedNames
  X-DeploymentMgr
  X-JMXMonitorMgr
  X-MonitoringDottedNames
  X-NotificationEmitterService=DomainNotificationEmitterService
  X-NotificationServiceMgr
  X-QueryMgr
  X-Sample
  X-SystemInfo
  X-UploadDownloadMgr
  X-WebServiceMgr
  J2EEDomain=amx
    J2EEServer=server
      J2EEApplication=__JWSappclients
        WebModule=//server/__JWSappclients
          Servlet=jsp
          Servlet=default
          Servlet=JWSSystemServlet
      J2EEApplication=MEjbApp
        EJBModule=mejb.jar
          StatelessSessionBean=MEJBBean
      J2EEApplication=__ejb_container_timer_app
        EJBModule=ejb.jar
          EntityBean=TimerBean
          EntityBean=TimerMigrationBean
      JDBCResource=jdbc/__TimerPool
      JVM=server1138655729031
      ResourceAdapterModule=__xa
        ResourceAdapter=__xa
      WebModule=//__asadmin/
        Servlet=DownloadServlet
        Servlet=ThemeServlet
        Servlet=AdminGUIServlet
        Servlet=ChartViewer
        Servlet=jsp
        Servlet=default
        Servlet=FacesServlet
        Servlet=UploadServlet
        Servlet=help2Servlet
        Servlet=HandleQuickStartDocs
      WebModule=//server/
        Servlet=jsp
        Servlet=default
      WebModule=//__asadmin/web1
        Servlet=ConnectServlet
        Servlet=AdminAPIEntryServlet
        Servlet=jsp
        Servlet=default
        Servlet=RemoteJmxConnectorServlet
        Servlet=UploadServlet
      WebModule=//__asadmin/asadmin
        Servlet=DownloadServlet
        Servlet=ThemeServlet
        Servlet=AdminGUIServlet
        Servlet=ChartViewer
        Servlet=jsp
        Servlet=default
        Servlet=FacesServlet
        Servlet=UploadServlet
        Servlet=help2Servlet
        Servlet=HandleQuickStartDocs
  X-DomainConfig
    X-ConfigConfig=default-config
      X-AdminServiceConfig
        X-DASConfig
        X-JMXConnectorConfig=system
          X-SSLConfig
      X-AvailabilityServiceConfig
        X-EJBContainerAvailabilityConfig
        X-JMSAvailabilityConfig
        X-WebContainerAvailabilityConfig
      X-DiagnosticServiceConfig
      X-EJBContainerConfig
        X-EJBTimerServiceConfig
      X-GroupManagementServiceConfig
      X-HTTPServiceConfig
        X-AccessLogConfig
        X-ConnectionPoolConfig
        X-HTTPFileCacheConfig
        X-HTTPListenerConfig=http-listener-2
        X-HTTPListenerConfig=http-listener-1
        X-HTTPProtocolConfig
        X-KeepAliveConfig
        X-RequestProcessingConfig
        X-VirtualServerConfig=server
          X-HTTPAccessLogConfig
      X-IIOPServiceConfig
        X-IIOPListenerConfig=orb-listener-1
        X-IIOPListenerConfig=SSL
          X-SSLConfig
        X-IIOPListenerConfig=SSL_MUTUALAUTH
          X-SSLConfig
        X-ORBConfig
      X-JMSServiceConfig
        X-JMSHostConfig=default_JMS_host
      X-JavaConfig
      X-LogServiceConfig
        X-ModuleLogLevelsConfig
      X-MDBContainerConfig
      X-ManagementRulesConfig
      X-MonitoringServiceConfig
        X-ModuleMonitoringLevelsConfig
      X-SecurityServiceConfig
        X-AuditModuleConfig=default
        X-AuthRealmConfig=file
        X-AuthRealmConfig=admin-realm
        X-AuthRealmConfig=certificate
        X-JACCProviderConfig=default
      X-ThreadPoolConfig=thread-pool-1
      X-TransactionServiceConfig
      X-WebContainerConfig
        X-SessionConfig
          X-SessionManagerConfig
            X-ManagerPropertiesConfig
            X-StorePropertiesConfig
          X-SessionPropertiesConfig
    X-ConfigConfig=server-config
      X-AdminServiceConfig
        X-DASConfig
        X-JMXConnectorConfig=system
          X-SSLConfig
      X-AvailabilityServiceConfig
        X-EJBContainerAvailabilityConfig
        X-JMSAvailabilityConfig
        X-WebContainerAvailabilityConfig
      X-DiagnosticServiceConfig
      X-EJBContainerConfig
        X-EJBTimerServiceConfig
      X-HTTPServiceConfig
        X-AccessLogConfig
        X-ConnectionPoolConfig
        X-HTTPFileCacheConfig
        X-HTTPListenerConfig=admin-listener
        X-HTTPListenerConfig=http-listener-2
        X-HTTPListenerConfig=http-listener-1
        X-HTTPProtocolConfig
        X-KeepAliveConfig
        X-RequestProcessingConfig
        X-VirtualServerConfig=__asadmin
          X-HTTPAccessLogConfig
        X-VirtualServerConfig=server
          X-HTTPAccessLogConfig
      X-IIOPServiceConfig
        X-IIOPListenerConfig=orb-listener-1
        X-IIOPListenerConfig=SSL
          X-SSLConfig
        X-IIOPListenerConfig=SSL_MUTUALAUTH
          X-SSLConfig
        X-ORBConfig
      X-JMSServiceConfig
        X-JMSHostConfig=default_JMS_host
      X-JavaConfig
      X-LogServiceConfig
        X-ModuleLogLevelsConfig
      X-MDBContainerConfig
      X-ManagementRulesConfig
      X-MonitoringServiceConfig
        X-ModuleMonitoringLevelsConfig
      X-SecurityServiceConfig
        X-AuditModuleConfig=default
        X-AuthRealmConfig=file
        X-AuthRealmConfig=admin-realm
        X-AuthRealmConfig=certificate
        X-JACCProviderConfig=default
        X-MessageSecurityConfig=SOAP
          X-ProviderConfig=ServerProvider
            X-RequestPolicyConfig
            X-ResponsePolicyConfig
          X-ProviderConfig=ClientProvider
            X-RequestPolicyConfig
            X-ResponsePolicyConfig
      X-ThreadPoolConfig=thread-pool-1
      X-TransactionServiceConfig
      X-WebContainerConfig
        X-SessionConfig
          X-SessionManagerConfig
            X-ManagerPropertiesConfig
            X-StorePropertiesConfig
          X-SessionPropertiesConfig
    X-J2EEApplicationConfig=__JWSappclients
    X-J2EEApplicationConfig=MEjbApp
    X-J2EEApplicationConfig=__ejb_container_timer_app
    X-JDBCConnectionPoolConfig=DerbyPool
    X-JDBCConnectionPoolConfig=__CallFlowPool
    X-JDBCConnectionPoolConfig=__TimerPool
    X-JDBCResourceConfig=jdbc/__TimerPool
    X-JDBCResourceConfig=jdbc/__CallFlowPool
    X-JDBCResourceConfig=jdbc/__default
    X-StandaloneServerConfig=server
      X-DeployedItemRefConfig=admingui
      X-DeployedItemRefConfig=__JWSappclients
      X-DeployedItemRefConfig=MEjbApp
      X-DeployedItemRefConfig=adminapp
      X-DeployedItemRefConfig=__ejb_container_timer_app
      X-ResourceRefConfig=jdbc/__CallFlowPool
      X-ResourceRefConfig=jdbc/__TimerPool
      X-ResourceRefConfig=jdbc/__default
    X-WebModuleConfig=admingui
    X-WebModuleConfig=adminapp
  X-MonitoringRoot
    X-ServerRootMonitor=server
      X-ApplicationMonitor=__JWSappclients
      X-CallFlowMonitor=server
      X-HTTPServiceMonitor
        X-HTTPServiceVirtualServerMonitor=server
      X-JVMMonitor
      X-Logging=server