Class Rules

Depending on the Sensor Rule type, a Class Rule defines one of the following:

  • For Method Rules it defines classes or interfaces, containing methods to be instrumented. It serves as a parent to Method Rules. Only methods, belonging to a class or an interface, matching parent Class Rule are evaluated by Method Rules.
  • For Memory Rules it defines classes or interfaces to be included to memory monitoring

Since Class Rules are defined within a Sensor Group, they inherit technology type (Java or .NET) from the group.

Configure a Class Rule in the Class Rule Properties dialog box:

  • While creating a new Class Rule:
    1. Open the System Profile Preferences dialog box, and select the Sensor item.
    2. Select the required Sensor Group and click Add Class.
  • While editing an existing Class Rule:
    1. Open the System Profile Preferences dialog box, and select the Sensor item.
    2. Select the required Sensor Group, select the Class Rule for editing and click Edit.

You can also add Class Rules by using the Class Browser.

Class pattern

Class Rules do not necessarily specify concrete names of classes/interfaces. Instead they use patterns which are evaluated when the names of the active classes are available. These patterns can be specified using one of the following modes:

  • equals: The pattern applies if the actual name is equal to the pattern text.
  • starts: The pattern applies if the actual name starts with the given pattern text.
  • ends: The pattern applies if the actual name ends with the given pattern text.
  • contains: The pattern applies if the actual name contains the given pattern text.
  • regex: Allows regular expressions. For example, ClassName[0-9]+ specifies all classes that start with ClassName followed by any number.

Notes

Use a regular expression only when necessary because of its impact on the CPU. A starts may be good enough if the classes are named efficiently.

A Class Rule with an empty pattern affects all classes. Such rules are ignored by the instrumentation engine due to possible performance penalties.

A Class Rule whose selection pattern ends with a dot is a package/namespace rule. It matches all classes within the specified package/namespace.

General

Specify Class Pattern: Class Rules are specified by patterns that are matches to the fully qualified class name and can also define interfaces or packages/namespaces.

Specify Classes by Annotations/Attributes: You can use Java Annotations or .NET Attributes as selection criteria for classes. You can specify one or several Annotations/.NET Attributes per Class Rule.

An Annotation/.NET Attribute specification consists of a mandatory type, which defines the full package/namespace name of the Annotation/.NET Attributes, an optional property, and a value.

If only Property is specified, and Value is omitted, only the Property existence are evaluated.
If both Property and Value are specified, the actual Values of Annotation/.NET Attribute Properties are compared with the specified Property Values. The specified Annotations/.NET Attributes are conjugated.
For example, a Class must provide all Annotations/.NET Attributes specified by a Class Rule to match said Rule.

To define a Class Rule that is based only on Annotations/.NET Attributes, leave the Class Pattern blank and switch the comparison mode to starts.

Options

Pattern declares a package: Determines if the Class Rule matches single classes or a whole package/namespace. A Class Rule defined for a package/namespace matches all Classes in the package/namespace.

Note

If you specify a package/namespace with mode equals, only classes contained in that package/namespace are processed, sub-packages are ignored.

Method Rules only Place: Enable or disable a Class Rule. For a Class Rule to take effect it should be actually placed.

Method Rules only Delegation Suppression: When Delegation Suppression is turned on, the Method Rules contained in that Class Rule are combined to one logical group. Each time one method matching one of these rules calls another method matching these rules, only the first call is shown in the corresponding PurePath. A method, such as read(), should be instrumented in one specific class, and also in all its super classes. You can do it by using the Inheritance property of the method. In this case a method calls the read() method of the super classes. As a result, there would be a chain of read() method calls in the PurePath.
To get a clearer PurePath, one could use Delegation Suppression to make all the following calls to read() disappear in the PurePath.

Memory Rules only Include Inherited Classes Includes inherited classes into instrumentation.