dcsimg
December 8, 2016
Hot Topics:

Standard MBeans

  • May 23, 2003
  • By O'Reilly & Associates
  • Send Email »
  • More Articles »

After looking at pattern #3, you may think that the management interface exposed by Worker is the union of BasicMBean and WorkerMBean. However, this is not the case. When this pattern is used, the introspection performed by the MBean server proceeds up the MBean interface inheritance graph, not the implementing inheritance graph. In Example 2-3, we see that WorkerMBean stands alone at the top of the inheritance graph. Regardless of the fact that Worker extends Basic (which implements BasicMBean), the management interface exposed proceeds no further than WorkerMBean. Thus, when this pattern is used, the management interface exposed by Worker is that shown in Example 2-3. However, should a reference to Worker be obtained, methods and attribute getters and setters inherited from Basic can be invoked (Java inheritance still works!). These inherited methods and attributes are not available to a management application, though, because they are not on the management interface.

Note also that any time a class implements an MBean interface that is at the top of an MBean hierarchy, the management interface exposed by that class is that MBean interface, regardless of any attributes and methods available to that class through Java inheritance. For example, suppose I have a child class of Worker called Supplier and Supplier implements SupplierMBean, which extends nothing:

public interface SupplierMBean {
//management interface here. . .
}
.
.
public class Supplier extends Worker implements SupplierMBean {
}

Again, you might think that the management interface exposed by Supplier is the union of BasicMBean, WorkerMBean, and SupplierMBean. However, this is not the case. Recall that in the earlier example where Worker extended Basic but implemented WorkerMBean, the management interface exposed was WorkerMBean. Similarly, in this case, the management interface exposed by Supplier is SupplierMBean. Java inheritance still works, and a reference to Supplier will give the holder of that reference access all the way up the inheritance graph, but a management application will have access only to those methods on the management interface exposed by Supplier.

Pattern #4: Simple inheritance with MBean inheritance

If WorkerMBean were to extend BasicMBean, pattern #3 would become pattern #4, and no further work would be required on the part of Worker to implement any methods from BasicMBean. This relationship is shown in Figure 2-4.

The MBean interface shown in Example 2-3 would simply need to be defined as:

public interface WorkerMBean extends BasicMBean {
//. . .
}

in order to implement this pattern. No code changes to Worker are required. Now, however, the management interface exposed by Worker is the union of BasicMBean and WorkerMBean.

Suppose that the Supplier class from pattern #3 has an MBean interface that extends WorkerMBean:

public interface SupplierMBean extends WorkerMBean {
//. . .
}

This relationship is shown in UML notation in Figure 2-5.

Figure 2-5. UML notation for a more complicated derivative of pattern #4

When the MBean server performs introspection, it will expose as the management interface all of the MBean interfaces until the top of the MBean inheritance graph is reached. This means that the management interface exposed by Supplier is the union of BasicMBean, WorkerMBean, and SupplierMBean.

The key to using this pattern is to remember that the MBean server uses MBean inheritance in addition to Java inheritance to determine the management interface. In other words, if you want your MBean interface to expose the management interface, you simply need to use the extends keyword when defining your MBean interface. Then your MBean interface will take advantage of Java inheritance as well.

Pattern #5: Compiler-enforced management interface inheritance

Suppose that, in pattern #4, Worker implements WorkerMBean but does not extend Basic. What then? Figure 2-6 shows this pattern in UML notation.

Figure 2-6. UML notation for pattern #5

Clearly, the compiler will not allow Worker to inherit an interface without implementing it. In pattern #4, because Worker extended Basic, BasicMBean came along for free through Java inheritance. But if Worker does not extend Basic, it is forced to implement BasicMBean, because WorkerMBean extends BasicMBean.

This may sound like an oversight at first, but it really isn't. This pattern allows you to customize the implementation of management interfaces while keeping the definitions of those interfaces semantically consistent. Carrying the Worker example further, suppose that you want the WorkerMBean management interface to be semantically identical to the union of WorkerMBean and BasicMBean. Logically, WorkerMBean should extend BasicMBean. However, suppose that you want to vary the implementation of BasicMBean provided by Basic. Using this pattern allows you to do this. And if you forget to implement anything from BasicMBean, the compiler will tell you!

Common Mistakes Not Caught by Introspection

The MBean server will catch and report most mistakes that you make in applying the standard MBean design patterns. However, there are mistakes you can make when applying the patterns that result in an MBean that is technically compliant but does not function as you intended. In this section, we will look at some of the most common mistakes you can make when instrumenting your application resources as standard MBeans that are not caught and reported by the MBean server. These mistakes are not caught by the Java compiler, either; your MBean simply will not work correctly. This section should aid you in troubleshooting the problem.

Mistake #1: MBean interface not given public visibility

This mistake is not caught by the compiler or reported by the MBean server. Suppose we mistakenly left off the public keyword from the interface definition for BasicMBean, using:

interface BasicMBean {
//. . .
}

instead of:

public interface BasicMBean {
//. . .
}

The Basic class implements BasicMBean as usual, and is registered by the agent:

public class Basic implements BasicMBean {
//. . .
}

To the MBean server, this MBean is compliant and is registered with no exceptions thrown. However, when the MBean server is asked to return the state of the MBean through its management interface, none of the attributes or operations can be accessed or invoked, respectively. A javax.management.ReflectionException is thrown by the MBean server at that time.

Mistake #2: Wrong return value type

The return value type of a getter must be never be void. Suppose we have a getter that is defined as:

public interface QueueMBean {
//. . .
  public void getQueueSize();
  public void setQueueSize(int value);
//. . .
}

In this example, the intended getter method is not considered by the MBean server to be a getter at all and instead is exposed as an operation on the management interface. A proper getter must return the type of its attribute.

The return value of a setter, however, must be void. This mistake is not caught by the compiler or reported by the MBean server, and it produces some pretty strange results. Example 2-1 showed the management interface for the Queue class. Notice the read/write attribute QueueSize:

public interface QueueMBean {
//. . .
  public int getQueueSize();
  public void setQueueSize(int);
//. . .
}

Suppose we provided a return value for setQueueSize():

public interface QueueMBean {
//. . .
  public int getQueueSize();
  public int setQueueSize(int value);
//. . .
}




Page 4 of 7



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel