Skip to end of banner
Go to start of banner

Sensor assignment with complex class/interface hierarchy

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Having a complex class and interface hierarchy sometimes makes it difficult to correctly assign the method sensors. This page shows several situations and examples on how to correctly configure monitoring of the wanted methods. 

Example 1: Method defined by interface implemented in super-class


As see from the UML diagram shown above, here we have the situation with two classes (abstract and concrete) and one interface. The interface is only implemented by the concrete class, but the method defined in the interface is implemented only in abstract class (although abstract class does not implement the given interface). So if we are interested in instrumenting the instrumentMe() method, how would we do it?

Concrete class directly?
sensor mySensor com.example.ConcreteClass instrumentMe

This will not work because the ConcreteClass does not declare or extend the method. 

Through interface?
sensor mySensor com.example.Interface instrumentMe interface=true�

This will also not work. The ConcreteClass does implement the interface but we will again not be able to find the instrumentMe() because it is not declared or extended in the ConcreteClass. Basically this instrumentation means if the class implement the interface, try to instrument instrumentMe() in that class.

Through super-class?
�sensor mySensor com.example.AbstractClass instrumentMe superclass=true 

Again, we have same problem as above. The ConcreteClass does extend the AbstractClass, but again method will not be located. This instrumentation means if the class extends the mentioned super-class, try to instrument instrumentMe() in that (concrete) class.

The solution is..
�sensor mySensor com.example.AbstractClass instrumentMe

Although it might seam non-logic at the first glance this is the only way to instrument the instrumentMe() in the given situation.  The confusion can come from the fact that in the JVM we might only have the instances of the ConcreteClass, thus all of these instances do have the instrumentMe() method. However, the JVM will load both classes and the method is defined only in the one of them - the abstract one. Thus we must go directly through the abstract one for the instrumentation.

The monitoring results displayed in the inspectIT will also display time spend in AsbtractClass.instrumentMe() although the instances of this class can not be created. This is due to the fact that the time is in fact spent in the AbstractClass implementation. 

Example 2: Method defined by interface implemented in super-class and extended in sub-class

Let's extend the first example by having the concrete class extending the instrumentMe() method:

class ConcreteClass extends AbstractClass {

	public void instrumentMe() {
		super.instrumentMe();
		// some other work
	}
}�

In this situations we can in fact instrument both instrumentMe() methods in two classes. Note that these are in fact two methods and time spend in both can be correctly measured. For instrumenting the method in the ConcreteClass we can use any of the three options that did not work for us in the first example because the class now extends the method:

3 ways to instrument instrumentMe() in ConcreteClass
sensor mySensor com.example.ConcreteClass method
sensor mySensor com.example.Interface method interface=true 
sensor mySensor com.example.AbstractClass method superclass=true

The only option to instrument the method in the AbstractClass stays the same as in example one.

Note that if both methods are instrumenting calling instrumentMe() on any ConcreteClass object will give us two times: t1 (time spent in ConcreteClass.instrumentMe()) and t2 (time spent in AbstractClass.instrumentMe()) where t1 = t2 + Δ, with delta time being time spend for "// some other work".

General recommendation with sensor assignemt

  • Prefer instrumenting the super-class over interface, cause sometimes the class that implements the interface does not declare the method defined by the interface
  • For instrumenting abstract method it's enough to include superclass=true of the abstract class that defines it

    sensor mySensor com.example.AbstractClass abstractMethod superclass=true
  • If abstract class defines the non-abstract method you want to monitor, instrument method in both abstract class and all sub-classes

    sensor mySensor com.example.AbstractClass nonAbstractMethod
    sensor mySensor com.example.AbstractClass nonAbstractMethod superclass=true

 

  • No labels