There are times when it is necessary to perform certain activities before and after an MBean is registered and deregistered. Implementing the MBeanRegistration interface provides an MBean with four opportunities (i.e., callbacks) to perform additional processing. The MBeanRegistration interface is defined as:

public interface MBeanRegistration {
  
  public ObjectName preRegister(MBeanServer server, ObjectName name)
    throws java.lang.Exception;
  
  public void postRegister(Boolean registrationDone);
  
  public void preDeregister(  )
    throws java.lang.Exception;
  
  public void postDeregister(  );
}

Another advantage of implementing this interface is that the MBean itself can generate its own object name in preRegister( ) , which is invoked prior to registering the MBean. The first opportunity an MBean has to perform any additional processing is in preRegister( ), which takes two parameters. The first parameter, server , is a reference to the MBean server in which the MBean will be registered, allowing an MBean to maintain a reference to its MBean server. The second parameter, name , is the object name of the MBean. The specification does not mention anything about the behavior of this method, other than that it is invoked prior to an MBean being registered. However, looking through the RI, it is clear that the designers of JMX intended that if the name parameter is null, the MBean will generate its own object name. Otherwise, name is returned unchanged.

Once the MBean has been registered, postRegister( ) is invoked with a boolean parameter, registrationDone , that indicates whether the registration was successful. If a problem occurred during registration, registrationDone will be false. Note that if an exception is thrown during the preRegister( ) callback, this method is never invoked.

If the agent that registered the MBean explicitly calls unregister( ) to deregister the MBean, the preDeregister( ) callback is invoked just prior to the MBean’s deregistration. This gives the MBean the opportunity to perform any necessary cleanup, such as releasing the reference to its MBean server. This callback method can very loosely be thought of as a destructor in C++, with the important difference that there is no guarantee that the MBean object is going away; it simply is not going to be manageable upon its deregistration.

Finally, following successful deregistration of the MBean, postDeregister( ) is called. If the preDeregister( ) callback threw an exception, this callback method is not invoked.

An implementation of this method on an MBean may look like this:

// . . .
  private MBeanServer _mbeanServer;
// . . .
  public ObjectName preRegister(MBeanServer server, ObjectName name)
    throws java.lang.Exception {
    _mbeanServer = server;
    if (name == null) {
      name = new ObjectName(server.getDefaultDomain(  ) + ":" + 
                            "name=Queue,objNameType=self");
    }
    return name;
  }
  
  public void postRegister(Boolean registrationDone) {
    if (!registrationDone)
      _mbeanServer = null;
  }
  
  public void preDeregister(  ) throws java.lang.Exception {
    _mbeanServer = null;
  }
  
  public void postDeregister(  ) {
    // do nothing. . .
  }
// . . .

In this example, preRegister( ) returns the object name passed to it (indicating that the agent registering the MBean has already generated an object name for the MBean) or, if it is passed null, creates an object name—I’ve made up a property called objNameType and set it to a value of self, indicating to a management application, or perhaps another JMX agent, that the MBean generated its own object name. The postRegister( ) callback method releases its reference to the MBean server if the registration fails. preDeregister( ) unconditionally releases its MBean server reference, and postDeregister( ) does nothing at all.