GlassFish MBean Annotation Library (gmbal)

Functional Specification

1. Introduction

The GlassFish MBean Annotation Library (gmbal, pronounced as in "gumball") is a runtime annotation processor that creates Open MBeans. This is useful for creating a management API for existing code with minimal effort.  It is intended to be applied to existing modules (which may be OSGi bundles in GlassFish v3, or any other packaging model including standard jar files), but could be used anywhere that it is desired to combine the definition of the management API with the module API and implementation.

Note that gmbal is not limited to use in GlassFish. Gmbal is completely independent of GlassFish, and may be used in a context where GlassFIsh is not present. However, when a gmbal-enabled module in used in GlassFish V3, that module will automatically be manageable using GlassFish V3 admin tools.

There are really two parts to creating a management API for a module: instrumenting the module implementation, and providing a client interface that may be accessed remotely. This is closely related to the AMX work in GFv3.  AMX defines the interface for AMX MBeans, and provides tools and libraries for clients accessing AMX MBeans.  Gmbal is a library that provides a mechanism for implementing AMXv3-compliant MBeans.

1.1. Alignment with related projects

• @ManagedAttribute is the same, except that gmbal allows overriding the id.
• @ManagedOperation is the same, except that gmbal allows overriding the id.
• @DescriptorKey is the same.
• @DescriptorFields is the same.
• @Description is similar to JSR 255, but does not support a bundleBaseName attribute. The bundle is set in gmbal through the ManagedObjectManager.setResourceBundle call.
  

• The packaging is necessarily different: org.glassfish.gmbal for gmbal, javax.management for JSR 255.
• Gmbal uses @ManagedObject instead of @MBean (part of JSR 255) or @MXBean.
• Gmbal only supports attribute change notifications, so the @NotificationInfo annotation (from JSR 255) does not exist in Gmbal.  See "register and registerAtRoot" for a discussion on notification support.
  
• Gmbal has an @ManagedData annotation to define the mapping of data types into CompositeData, while JSR 255 follows MXBeans and simply assumes that all methods that follow the JavaBeans patterns define read-only attributes.
• Gmbal supports an @AMXMetadata annotation, but this is really just an extension to the descriptor annotation mechanism borrowed from JMX ModelMBeans.  The @AMXMetadata annotation is provided to support AMX-specific metadata.
• Gmbal includes @ParameterNames to provide reasonable names for the arguments on MBean operations.  JSR 255 does not currently have such a mechanism, because JDK 7 will have an extension to Java reflection that captures the argument names on methods.
• Gmbal includes @NameValue to make it easy to define the value of the "name" field in the ObjectName. This makes registration of object as MBeans slightly simpler.
• Gmbal includes @IncludeSubclass, which allows limited (and closed) polymorphism for CompositeData.  This partially solves the problem of mapping a group of types sharing type Base that appear as (for example) attributes with type List<Base>.
• Gmbal includes @InheritedAttribute(s) to allow using methods inherited from super classes or super interfaces that cannot be annotated as attribute and operations.
• Gmbal is more limited currently in mapping OpenType -> Java type than JMX is, as this does not seem to be a feature that we need.
  

1.2. Similar projects

2. The Management Data Model

• A ManagedObjectManager acts as a container for all state related to a particular usage of gmbal. This includes:
  • A domain to use for all ObjectNames created in this ManagedObjectManager.
  • A rootParentName, which is the ObjectName of the parent of the ManagedObjectManager.
  • A root object, which represents the top of the tree of MBean managed by the ManagedObjectManager.
    
• From a POJO with annotations, an MBeanImpl is constructed, which implements the dynamic MBean API.  This dynamic MBean is associated with additional classes:
  • 0 or more Attributes, which may be getters or setters or both (note that AMX will give as at least Name, Parent, and Children attributes).
    
  • 0 or more Operations, which may be invoked.
  • Metadata, represented by ModelMBeanInfoSupport (so that metadata Descriptors are available on JDK 5 as well as JDK 6). The Metadata is extensible through the use of the @DescriptorKey and @DescriptorField meta-annotations.
    
  • A single parent MBeanImpl, which may be null (this is one end of the contains relation).
  • 0 or more child MBeanImpls (this is the other end of the contains relation).
  • Following AMXv3, the ObjectName of the MBean will contain 3 name/value pairs:
  • pp, which is the AMXv3 parent path, or the path name of the parent of this MBean
  • type, which is derived from the Class using annotations or other mechanisms
  • name, which is derived either from the registration call, or a method on the object.  The name is absent in the case of a singleton.  In any case, the type and name (if present) must be unique within the scope of the parent.
    
• Attributes and Operations have ids, which are generally derived from the name of the annotated method as discussed here, but the id may also be specified in the @ManagedAttribute and @ManagedOperation annotations, as well as in the @InheritedAttribute annotation.
  

3. Interfaces

1. class ManagedObjectManagerFactory, which provides factory methods for creating instance of the ManagedObjectManager interface.
2. interface ManagedObjectManager, which provides register/deregister methods (and a number of other capabilities).
3. A number of annotations.
   

• The primitives (boolean, byte, char, short, int, long, float, double) and the corresponding java.lang wrapper classes (Boolean, Byte, Character, Short, Integer, Long, Float, Double).
• String
• BigDecimal, BigInteger
• Date
• ObjectName
• Class
• Number
• Object
  

3.1. The ManagedObjectManagerFactory

3.1.1. getMethod

3.1.2. create

3.2. The ManagedObjectManager

3.2.1. createRoot

3.2.2. getRoot

3.2.3. register and registerAtRoot

3.2.4. unregister

3.2.5. getObject/getObjectName

3.2.6. stripPrefix and stripPackagePrefix

3.2.7. MBeanServer and ResourceBundle

3.2.8. addAnnotation

@ManagedData
Servant get_servant() { ... }

@ManagedData
@InheritedAttributes( {
    @InheritedAttribute( methodName="_object_id", id="objectId",
        description="The Object Id for this Servant" ),
    ... // several other methods
} )
public interface DummyServant {}

mom.addAnnotation( Servant.class, 
    DummyServant.class.getAnnotation( ManagedObject.class ) ) ;
mom.addAnnotation( Servant.class, 
    DummyServant.class.getAnnotation( InheritedAttributes.class ) ) ;

@ManagedData
@Description( "A template for creating a TaggedProfile" ) 
@IncludeSubclass( { com.sun.corba.se.spi.ior.iiop.IIOPProfileTemplate.class } )
@InheritedAttribute( description="List of TaggedComponents for this template",
    methodName="iterator", id="TaggedComponents" )
public interface TaggedProfileTemplate extends List<TaggedComponent>, 
    Identifiable, WriteContents, MakeImmutable
{ 
    ...  
}

Here the iterator method is inherited from List<TaggedComponent>.  The iterator() method then has type Iterator<T>, where T is bound to TaggedComponent. This results in a CompositeData attribute with id TaggedComponents, which returns an OpenType which is an array of whatever TaggedComponent maps to (CompositeData as discussed in "Handling Polymorphism").

3.2.9. Debugging support

• setRegistrationDebugLevel( RegistrationDebugLevel level ).  Here the level can be NONE, NORMAL, or FINE.  When enabled, this method causes detailed tracing (more detailed with FINE) of the operations involved in registering an MBean.
• setRuntimeDebugLevel( boolean flag ).  If this is enabled, the operations involved in getting or setting attributes or calling an operation on an MBean are traced.
• setTypelibDebug( int level ).  This is used to trace typelib operations.  1 traces only basic operation, while >1 gives full details (produces a lot of output).
  
• String dumpSkeleton( Object obj ).  If obj is an object that has been registered with the ManagedObjectManager, this returns a String dump of the MBeanSkeleton object, which provides detailed information about the exact attributes and operations supported by the MBean.

3.2.10. Close

The close call is provided to unregister all MBeans still registered with the MBeanServer, and to release all internal state maintained by the ManagedObjectManager. Note that the registered MBeans are unregistered and destroyed bottom up, to preserve the AMX requirements that children cannot exist without their parent existing (see section 5.1 "Parent must exist" of the AMX SPI specification).

3.2.11. suspendJMXRegistration/resumeJMXRegistration

3.2.12. getAMXClient

3.2.13. getDomain

3.2.14. isManagedObject

3.2.15. suppressDuplicateRootReport

4. Further notes on the API

4.1. Processing of method names for IDs

1. If the method is annotated with @ManagedAttribute:
   
   1. If the method is a getter (that is, it has no arguments and a non-void result):
      1. If the method name starts with "get" or "is", remote the prefix.  The rest of the method name is the attribute ID for an attribute in a ManagedObject.  If the attribute is in a ManagedData, then the first character is forced to lower case.
         
      2. Otherwise the method name is the id.
         
   2. If the method is a setter (that, has one argument and a void result):
      1. If the method name starts with "set", remove "set". The rest of the method name is the attribute ID for an attribute in a ManagedObject.  If the attribute is in a ManagedData, then the first character is forced to lower case. 
      2. Otherwise the method name is the id.
   3. Otherwise the method is not a valid attribute, and an exception will be thrown
      
2. If the method is annotated with @ManagedOperation:
   1. The id is the method name.

4.2. I18N support

4.3. OpenType mapping

1. Gmbal supports all Collection, Iterator, Iterable, and Enumeration types where MXBeans support List, Set, and SortedSet.
2. Gmbal also maps Dictionary as well as Map to TabularType.
3. Gmbal maps all @ManagedObject types to ObjectName (in MXBeans, this is any MXBean interface).
4. Gmbal only maps other types to CompositeData if the type has an @ManagedData annotation.  If not, gmbal maps the type to a String using its toString() method.
5. Gmbal does not support reconstructing a Java type from CompositeData. Gmbal could be extended in this area if necessary.
6. Gmbal will provide more support for converting generic types into generic MBean types, which can be instantiated into specific MBeans based on the actual type parameters supplied to an instance of the generic type.

4.4. Metadata support

@AMXMetadata
public interface MyBean1 { ... }

In this case, MyBean1 is a singleton (only one of this type may appear in the same parent), its MBean info never changes, the proxy interface name defaults to a generic implementation, the group is other, and the list of valid subtypes is empty, which means any type may appear as a child.  Note that the @AMXMetadata annotation is not needed at all in this case.

Something like

@AMXMetadata( isSingleton=false, type=Widget )
public interface MyBean2 { ... }

defines an AMX MBean which is not a singleton.  Also, the type will be set to Widget in the ObjectName created for an instance of MyBean2.

4.5. AMX support for MBeans

• Creating ObjectNames according to the parent/child hierarchy.  Gmbal will never put anything in an ObjectName that is not part of the AMX specification.
• Supporting the MBeanInfo Descriptor.  This is handled in gmbal through the @AMXMetadata annotation.
• All MBeans created using gmbal will include all of the attributes defined in section 4.0 "Attributes" of the AMX SPI spec.
• Gmbal will only use Open data types for MBean attribute values and operation arguments and results.  But gmbal will map most Java data types to the appropriate Open data types, following the MXBean specification (with some differences; see "OpenType mapping").
  
• Gmbal will support all of the behavior requirements of section 5 of the AMX SPI spec.  This include support for AttributeChangeNotification.
  

4.6. Using Gmbal

1. Add annotations to existing application objects (here application means anything you want to manage, part of GFv3 or not) to expose attributes and operations.
2. In some cases you may need to expose some data by defining new methods.  Currently all gmbal visible annotations must be public, but I may relax that (at the cost of requiring an access check permission for reflection).
3. In the initialization of a module, create an appropriate ManagedObjectManager (call it mom).  This requires thinking about where in the federated hierarchy the root of the ManagedObjectManager should live.  In some cases, this may be different depending on the environment in which the instrumented code runs.
4. Whenever an Object is created that requires a management interface, register that object with the mom.
5. Whenever an Object is no longer needed, unregister that object with the mom.
6. Whenever the module lifecycle ends, call mom.close() to clean up the root object and any other remaining registered objects.

    // mom is declared the ORB object, which stays around the entire time the ORB is in use.
    // Here I am using createStandalone.  This needs to be replaced with a call to createFederated
    // when running in GlassFish v3.  This will be driven through the ORB configuration.
    mom = ManagedObjectManagerFactory.createStandalone( "com.sun.corba" ) ;

    // The ORB already has a system for setting debug options, so I just extended it for gmbal.
    if (mbeanFineDebugFlag) {
        mom.setRegistrationDebug( ManagedObjectManager.RegistrationDebugLevel.FINE ) ;
    } else if (mbeanDebugFlag) {
        mom.setRegistrationDebug( ManagedObjectManager.RegistrationDebugLevel.NORMAL ) ;
    } else {
        mom.setRegistrationDebug( ManagedObjectManager.RegistrationDebugLevel.NONE ) ;
    }

    mom.setRuntimeDebug( mbeanRuntimeDebugFlag ) ;

    // Here I add all of the package prefixes that I do NOT want to see in ObjectNames.
    // The longest match is stripped from the class name to create the default value for the
    // type.
    mom.stripPrefix( "com.sun.corba.se" ) ;
    mom.stripPrefix( "com.sun.corba.se.spi" ) ;
    mom.stripPrefix( "com.sun.corba.se.impl" ) ;
    mom.stripPrefix( "com.sun.corba.se.spi.orbutil" ) ;
    mom.stripPrefix( "com.sun.corba.se.impl.orbutil" ) ;

    // Here I am using the guaranteed to be unique ORB id as the name of the topmost ORB mbean.
    mom.createRoot( this, getUniqueOrbId() ) ;

In order to integrate the ORB with GlassFish v3, there is quite a bit of GlassFish v3-specific code that initializes the ORB. This code will need to be placed in an appropriate OSGi bundle (either in the EJB remote bundle, or possible in a separate embedded ORB support bundle). Then the ORB SPI needs to be extended to support a call like setMBeanRootParent( ObjectName ).  If this method is called (which would normally only happen from inside the ORB support code in GlassFish v3), the initialization sequence needs to call ManagedObjectManagerFactory.createFederated instead of createStandalone.  Everything else stays exactly the same, giving an easy way to run the ORB either in GlassFish v3, or standalone (for example, as part of JDK 7, if we get to that).

Next we need to see an example of MBean creation code.  Again the example is from the GFv3 ORB, this time in the timer subsystem (from the orblibrary package com.sun.corba.se.spi.orbutil.newtimer). The timer subsystem defines a number of different interfaces (e.g. Timer, TimerGroup, TimerFactory, StatsEventHandler among others), instances of which are registered as MBeans. Each of these classes extends a base interface called Named defined as follows:

public interface Named {
    /** Return the TimerFactory that created this Named.
     */
    @ManagedAttribute
    @Description( "TimerFactory that created this Timer or TimerGroup" ) 
    TimerFactory factory() ;

    /** A short name for this Controllable.
     */
    @ManagedAttribute
    @NameValue
    @Description( "Name of this Timer or TimerGroup" ) 
    String name() ;
}

Note that the name() attribute carries the @NameValue attribute.  This simplifies the registration which takes place in TimerFactoryImpl.  The TimerFactoryImpl contains all of the factory methods for creating the various timer interfaces mentioned previously. TimerFactoryImpl defines several private methods as follows:

    private void manage( Named obj ) {
        // Note that no extra parameters are needed here, because Named.getName
        // is an NameValue.
        if (mom != null)  {
            // System.out.println( "Registering " + obj ) ;
            mom.registerAtRoot( obj ) ;
        }
    }

    private void manage( Named parent, Named obj ) {
        // Note that no extra parameters are needed here, because Named.getName
        // is an NameValue.
        if (mom != null)  {
            // System.out.println( "Registering " + obj ) ;
            mom.register( parent, obj ) ;
        }
    }

    private void unmanage( Named obj ) {
        if (mom != null) 
            mom.unregister( obj ) ;
    }

These methods support the case where no ManagedObjectManager (mom) is present, which may be a useful pattern in other cases. For example, Grizzly must be able to run in as small a configuration as possible, but Grizzly would like to have MBeans available as an option. Consequently, the gmbal annotations and API (plus one small utility class) are defined in the gmbal-api-only bundle (about 14K).  Another bundle (gmbal, about 240K) includes everything in gmbal-api-only, plus a full implementation.  One  of the bundles gmbal-api-only or gmbal needs to be present in all cases, and all of the code in this example requires ONLY gmbal-api-only.  If gmbal is NOT available, ManagedObjectManagerFactory.createStandalone and createFederated will return an instance of a no-op implementation of ManagedObjectManager. This would allow the above code to avoid the null check, which was required in an older version of gmbal.

Now consider actually creating instances of various timer classes. FIrst, the TimerManager is itself represented by an MBean, so it must be registered. It is tempting to do this in the constructor (in fact, this mistake has been made in the ORB). You should not do this!  Calling mom.register( this ) in the constructor violates one of the cardinal rules of Java concurrent programming: do not publish objects before construction is complete.  As soon as the mom.register call returns, the MBean has been registered with the ManagedObjectManager's MBeanServer, and this means that remove invocations on unknown thread could arrive at any moment, including before the constructor has returned. Note that any method of an object that is used at an attribute or operation MUST be thread safe, as such a method can be invoked at any by one or more threads from remote JMX connectors.

However, there are times when the constructor is the only reasonable place to do the registration. This happen in situations where:

• There is a top-level constructor that initializes a large hierarchy of objects.
• The top-level constructor needs to create the ManagedObjectManager and root before it initializes the other objects that need a ManagedObjectManager.
• Since creating the root registers an MBean, we don't normally want to do this in the constructor

In the timer library case, the TimerFactory is constructed by a TimerFactoryBuilder as follows:

    public synchronized static TimerFactory make( ManagedObjectManager mom, 
        String name, String description ) {

	if (fmap.get( name ) != null)
	    throw new IllegalArgumentException(
		"There is currently a TimerFactory named " + name ) ;

	TimerFactory result = new TimerFactoryImpl( mom, name, description ) ;
	fmap.put( name, result ) ;
        mom.register( result ) ; // registered AFTER construction as a child of mom's root
	return result ;
    }

Here's an example of registering a TimerGroup (from TimerFactory):

    public synchronized TimerGroup makeTimerGroup( String name, 
	String description ) {

	checkArgs( timerGroups.keySet(), name, description ) ;

	TimerGroupImpl result = new TimerGroupImpl( nextIndex, this, name, 
	    description ) ;
        manage( this, result ) ;

	mapId( result ) ;
	timerGroups.put( result.name(), result ) ;
	add( result ) ;  // Remember, a TimerFactory is a TimerGroup 
			 // containing all
		         // Controllables that it creates!

	return result ;
    }

Here the TimerGroup has an MBean that is registered as a child of the TimerFactory. The TimerGroup interface itself is annotated as follows:

@ManagedObject
@Description( "A group of Timers or other TimerGroups, which may be enabled or disabled together" ) 
public interface TimerGroup extends Controllable {
    @ManagedOperation
    @Description( "Add a new Timer or TimerGroup to this TimerGroup" ) 
    boolean add( Controllable con ) ;

    @ManagedOperation
    @Description( "Remove a new Timer or TimerGroup from this TimerGroup" ) 
    boolean remove( Controllable con ) ;
}

Controllable is fairly complex, and defines a number of attributes:

@ManagedObject
@IncludeSubclass( { Timer.class, TimerGroup.class, TimerFactory.class } ) 
public interface Controllable extends Named {
    /** A longer description giving some details of the meaning of this
     * Controllable.
     */
    @ManagedAttribute
    @Description( "The purpose of the Timer or TimerGroup" ) 
    String description() ;

    /** A small id for this controllable.  Each controllable created from
     * the same TimerFactory will have a unique ID.  All ids will be small
     * integers starting at 0 (so indexing tables by timer ID is supported).
     */
    @ManagedAttribute
    @Description( "An internal identifier for the Timer or TimerGroup" ) 
    int id() ;objectClass

    /** Return an unmodifiable set of the contents of this Controllable.
     * May always be empty for some subclasses of Controllable.
     */
    @ManagedAttribute
    @Description( "Set of Timers or TimerGroups contained in a TimerGroup" )
    Set<? extends Controllable> contents() ;

    /** Enable this controllable.  All Timers that are either enabled, or
     * reachable via contents() from an enabled Controllable are activated,
     * and will cause TimerEvents to be generated when passed to the
     * TimerEventController enter and exit methods.
     */ 
    @ManagedOperation
    @Description( "Enable this Timer, or all Timers and TimerGroups contained in this TimerGroup" ) 
    void enable() ;

    /** Disable this controllable.
     */
    @ManagedOperation
    @Description( "Disable this Timer, or all Timers and TimerGroups contained in this TimerGroup" ) 
    void disable() ;

    /** Return true if enable() was called, otherwise false if enable() was never
     * called, or disable() was last called.
     */
    @ManagedOperation
    @Description( "True if this Timer or TimerGroup is enabled" ) 
    boolean isEnabled() ;
}

Because TimerGroup extends Controllable extends Named, the TimerGroup inherits the name() attribute which is annotated with @NameValue. This means that the result of calling timerGroup.name() is used as the value of the name attribute in the ObjectName for the MBean constructed for timerGroup.

Finally, when an object is no longer needed, the ManagedObjectManager.unregister method must be called. In some case this is handled through an explicit method to remove the object, e.g. for TimerEventHandle in the TimerFactory.removeTimerEventHandler method:

    public synchronized void removeTimerEventHandler( 
	TimerEventHandler handler ) {

	timerEventHandlers.remove( handler.name() ) ;
        unmanage( handler ) ;
    }

If the mbeans should be registered as long as the module exists, ManagedObjectManager.close() can be used to unregister everything. In the case of the ORB, the close call should happen in the ORB.destroy code. 

4.7. Handling Polymorphism

/** Generic interface for all tagged components.  Users of the ORB may
* create implementations of this class and also corresponding factories
* of type TaggedComponentFactory.  The factories can be registered with an
* ORB instance, in which case they will be used to unmarshal IORs containing
* the registered tagged component.
*/
@ManagedData
@Description( "Base class for all TaggedComponents" )
@IncludeSubclass( { AlternateIIOPAddressComponent.class, 
    CodeSetsComponent.class, JavaCodebaseComponent.class,
    MaxStreamFormatVersionComponent.class, ORBTypeComponent.class,
    RequestPartitioningComponent.class,
    GenericTaggedComponent.class } )
public interface TaggedComponent extends Identifiable
{
    org.omg.IOP.TaggedComponent getIOPComponent( ORB orb ) ;
}

then, an example of two of the subclasses:

@ManagedData
@Description( "Component containing an alternate IIOP address to use" )
public interface AlternateIIOPAddressComponent extends TaggedComponent
{
    @ManagedAttribute
    @Description( "The Alternate address" ) 
    public IIOPAddress getAddress() ;
}

@ManagedData
@Description( "Component representing Codebase URLs for downloading code" )
public interface JavaCodebaseComponent extends TaggedComponent 
{
    @ManagedAttribute
    @Description( "List of URLs in the codebase" ) 
    public String getURLs() ;
}

The result of this is that any reference to the TaggedComponent type in a @ManagedObject will mapped to CompositeData with the Address and URLs attributes.  However, the actual CompositeData to which an instance of TaggedComponent is mapped will only have Address if it isA AlternateIIOPAddressComponent, otherwise that attribute will be unavailable.  If TaggedComponent defined any attributes, those attributes would be present in all instance of CompositeData representing a TaggedComponent (in this case the org.omg.IOP.TaggedComponent type is simply not interesting enough to expose as an Attribute).

4.8. Issues with generic types

This is best explained with an example.  Suppose we have interfaces defined as follows:

@ManagedData
public interface ExampleData<S,T> {
    S       getInfo() ;

    List<T> getData() ;
}

public interface Example<S,T> {
    @ManagedAttribute
    ExampleData<S,T> getInfo() ;
}

@ManagedObject
public interface MyBean extends Example<Date,List<String>> {
}

• id=info, type=Object (since type is type variable S)
• id=data, type=Object (since type is type variable T)
  

• id=info, type=Date
• id=data, type=List<List<String>>

4.9. Issues with recursive types

@ManagedData
public interface A {
    @ManagedAttribute
    B getB() ;
}

@ManagedData
public interface B {
    @ManagedAttribute
    A getA() ;
}

@ManagedData 
public interface A {
    @ManagedAttribute
    String getName() ;

    @ManagedAttribute
    B getB() ;
}

@ManagedData
public interface B {
    @ManagedAttribute( id="A" ) 
    String getARef() ; // returns getA().getName()

    A getA() ;
}

4.10 Method call order requirements

• Methods that can only be called before the first successful call to a createRoot method:
  
• the 3 createRoot methods
  
• stripPrefix
• stripPackagePrefix
• setResourceBundle
• setMBeanServer
  
• addAnnotation
• Methods that can only be called after the first successful call to a createRoot method:
• The 2 register methods
• The 2 registerAtRoot methods
• unregister
• getRoot
• getObject
• getObjectName
  
• Methods that can be called at any time:
• getResourceBundle
• getMBeanServer
• getDomain
  
• suspendJMXRegistration
• resumeJMXRegistration
• setRuntimeDebug
• setRegistrationDebug
• setTypelibDebug
  

4.11. Computing the type name

1. If the class contains a final static field of type String name AMX_TYPE, the value of the field is the type.
2. Otherwise, if the class has an annotation @AMXMetadata and the type field is not "", the type field is the type.
3. Otherwise, if the package prefix of the class name matches one of the stripPrefix call arguments, that part of the package prefix is removed from the full class name, and the remainder (minus the initial dot) is the type name.
4. Otherwise, if stripPackagePrefix was called, the entire package prefix is removed (if any), and the remaining class name is the type name.
5. Otherwise, the full class name is the type name.

1. If the class contains a final static field of type String name GMBAL_TYPE, the value of the field is the name.
2. Otherwise, if the class's @ManagedData annotation has a name element with a value other than "", the value of the name element is the name.
3. Otherwise, if the package prefix of the class name matches one of the stripPrefix call arguments, that part of the package prefix is removed from the full class name, and the remainder (minus the initial dot) is the name.
4. Otherwise, if stripPackagePrefix was called, the entire package prefix is removed (if any), and the remaining class name is the type name.
5. Otherwise, the full class name is the name.

5. Dependencies

6. Testing

7. Project Details