Page History
...
| Info |
|---|
Custom instrumentation is only recommended for very specific instrumentation needs. In other cases, it is recommended to use the Monitoring Configuration or Adaptive Instrumentation options, available in the Monitor Settings dialog box (Settings>Monitor Settings). For more information regarding these instrumentation options, the “About Monitoring Configuration” section in the Precise for J2EE User’s Guide. |
About modifying instrumenter configuration files
Instrumentation instructions are contained in a series of XML files that can be found in the Precise for J2EE agent installation on the host where the monitored JVM runs. The InstrumenterConfigList.xml file, which also exists in each monitored JVM’s configuration directory, references the instrumentation configuration files. See About instrumenter configuration file reference .
How you modify your instrumentation configuration depends on what you try to do:
...
<config-file> ${indepth.j2ee.home}/config/${indepth.j2ee.server_id}/Custom.xml </config-file>
Enabling an additional configuration file
The following procedure describes how you can enable an additional configuration file.
...
- Open the InstrumenterConfigList.xml file in the JVM ID-specific configuration directory for your application server:
<i3_root>/products/i3fp/registry/products/j2ee/config/JVMID/ - In the InstrumenterConfigList.xml file, locate the XML block that defines the file you want to enable. For example, to enable the JNDI custom instrumentation file, locate the following section:
<!--
JNDI
Uncomment to instrument.
-->
<!--
<config-file>
JNDI.xml
</config-file>
--> - Remove the XML comments surrounding the file name. For example:
<!--
JNDI
Uncomment to instrument.
-->
<config-file>
JNDI.xml
</config-file>
Adding your own custom instrumentation configuration file
The following procedure describes how you can add your own custom instrumentation configuration file.
...
- Create a new user-defined XML configuration file, for example:
UserDefined.xml, in the following way:
<?xml version="1.0" encoding="UTF-8"?>
<!--
User Defined Instrumenter Configuration File
-->
<instrumenter-config>
<custom-config>
<java-classes>
<java-class>
<class-name>
</class-name>
<methods>
<method>
<name>
</name>
</method>
</methods>
</java-class>
</java-classes>
</custom-config>
</instrumenter-config> - To add the file to the InstrumenterConfigList.xml file, use the following syntax:
<!--
User defined instrumenter config file
-->
<config-file>
UserDefined.xml
</config-file> - Modify the new XML configuration file to include the interfaces, classes, and methods you want to instrument. See the next section for more information.
About custom instrumenter configuration
Precise for J2EE allows you great flexibility in instrumenting Java applications. You can instrument specifically named packages, interfaces, classes, and methods. In addition, you can instrument all classes in a package or all methods in a class using the wildcard character. Sub-elements of <instrumenter-config> also allow you to target the behavior of methods so that you can instrument all calls to a method as well as all calls the method makes, or calls from a specific method to another specific method. Precise for J2EE instrumentation also takes advantage of various Java language properties, allowing you, for example, to instrument all classes that extend a common subclass or interface, or to instrument classes and methods marked with a runtime-visible annotation.
...
@Resource
public class RecoverableTaskAdapter extends AbstractTask implements RecoverableTask {
public void start() { }
public void start(RecoverableTaskContext context) { }
protected void recover(RecoverableTaskContext context) { }
public void stop() { }
public void stop(boolean force) { }
}
About instrumenting interfaces
Instrumentation can be applied to methods in abstract and concrete classes that implement specific interfaces.
About instrumenting methods in implementations of an interface
The <custom-config> element can be used to cause instrumentation to be applied to methods of abstract and concrete classes that implement an interface.
...
AbstractTask.start(TaskContext)because the method was not declared in the Task interface.RecoverableTaskAdapter.start(TaskContext)because the method was not declared in the Task interface.RecoverableTaskAdapter.recover(RecoverableTaskContext)because the method was not declared in the Task interface.
About restricting instrumentation to methods that match a signature
The <params> element can be included within a <method> element to restrict instrumentation to a method that is based on a signature. See About method signature matching.
This instrumenter configuration file causes instrumentation to be applied to the start and stop(boolean) methods of abstract and concrete classes that implement the Task interface.
...
AbstractTask.start(TaskContext)because the method was not declared in the Task interface.AbstractTask.stop()because the method does not match the specified signature of (boolean).RecoverableTaskAdapter.start(TaskContext)because the method was not declared in the Task interface.RecoverableTaskAdapter.recover(RecoverableTaskContext)because the method was not declared in the Task interface.RecoverableTaskAdapter.stop()because the method does not match the specified signature of (boolean). See About method signature matching.
About extending instrumentation to interfaces matching a wildcard
Inheritance is not considered when wildcards are used with <class-name> element. It is not possible to use wildcards to cause instrumentation to be applied to all abstract or concrete class's that implement interface's that match a wildcard pattern.
However, wildcards can be used to apply instrumentation to all abstract or concrete classes whose names match the wildcard pattern that is specified in the <class-name> element.
See About using the wildcard character *.
About extending instrumentation to methods that match a wildcard
Wildcards can be used in the <name> element. This instrumenter configuration file causes instrumentation to be applied to the start() and stop() methods of abstract and concrete classes that implement the Task interface.
...
AbstractTask.start(TaskContext)because the method was not declared in the Task interface.AbstractTask.stop(boolean)because the method does not match the specified signature of ().RecoverableTaskAdapter.start(TaskContext)because the method was not declared in the Task interface.RecoverableTaskAdapter.recover(RecoverableTaskContext)because the method name does not match the wildcard pattern.RecoverableTaskAdapter.stop(boolean)because the method does not match the signature of ().
About extending instrumentation to methods that are declared in extending interfaces
By default, instrumentation is restricted to methods that are declared in the matching interface. The <apply-to-subtypes> element can be used to extend instrumentation to apply to methods that are declared in extending interfaces.
...
AbstractTask.start(TaskContext)because the method was not declared in the Task interface or in an interface that extends the Task interface.AbstractTask.stop()because the method does not match the specified wildcard pattern of sta*.AbstractTask.stop(boolean)because the method does not match the specified wildcard pattern of sta*.RecoverableTaskAdapter.recover(RecoverableTaskContext)because the method name does not match the specified wildcard pattern of sta*.RecoverableTaskAdapter.stop()because the method does not match the specified wildcard pattern of sta*.RecoverableTaskAdapter.stop(boolean)because the method does not match the specified wildcard pattern of sta*.
About extending wildcards to apply to methods that are declared in implementations
By default, instrumentation is restricted to methods that are declared in the matching interface. The <apply-to-implementations> element can be used to extend instrumentation to apply to methods that are declared in abstract and concrete classes that implement the matching interface.
...
AbstractTask.stop()because the method does not match the specified wildcard pattern of sta*.AbstractTask.stop(boolean)because the method does not match the specified wildcard pattern of sta*.RecoverableTaskAdapter.recover(RecoverableTaskContext)because the method name does not match the specified wildcard pattern of sta*.RecoverableTaskAdapter.stop()because the method does not match the specified wildcard pattern of sta*.RecoverableTaskAdapter.stop(boolean)because the method does not match the specified wildcard pattern of sta*.
About instrumenting classes
Instrumentation can be applied to methods in abstract and concrete classes.
About instrumenting methods in abstract and concrete classes
The <custom-config> element can be used to cause instrumentation to be applied to methods of abstract and concrete classes.
...
RecoverableTaskAdapter.recover(RecoverableTaskContent)because the method was not declared in the AbstractTask class
About restricting instrumentation to methods that match a signature
The <params> element can be included within a <method> element to restrict instrumentation to a method that is based on signature.
...
AbstractTask.stop()because the method does not match the specified signature of (boolean).RecoverableTaskAdapter.recover(RecoverableTaskContext)because the method was not declared in the AbstractTask class.RecoverableTaskAdapter.stop()because the method does not match the specified signature of (boolean) See About method signature matching.
About extending instrumentation to classes matching a wildcard
Inheritance is not considered when wildcards are used with a <class-name> element. It is not possible to use wildcards to cause instrumentation to be applied to all abstract or concrete classes that extend classes that match a wildcard pattern.
However, wildcards can be used to apply instrumentation to all abstract or concrete classes whose names match the wildcard pattern that is specified in the <class-name> element.
About extending instrumentation to methods that match a wildcard
Wildcards can be used in the <name> element.
This instrumenter configuration file causes instrumentation to be applied to the start() and stop() methods of abstract and concrete classes that extend the AbstractTask class. See About using the wildcard character *.
<?xml version='1.0'?>
<instrumenter-config>
<custom-config>
<java-classes>
<java-class>
<class-name> xmp.wfm.task.AbstractTask </class-name>
<methods>
<method>
<name> s* </name>
<params> <params/>
</method>
</methods>
</java-class>
</java-classes>
</custom-config>
</instrumenter-config>
...
AbstractTask.stop(boolean)because the method does not match the specified signature of ().RecoverableTaskAdapter.recover(RecoverableTaskContext)because the method name does not match the wildcard pattern.RecoverableTaskAdapter.stop(boolean)because the method does not match the specified signature of ().
About extending instrumentation to methods that are declared in extending classes
By default, instrumentation is restricted to methods that are declared in the matching class. The <apply-to-subtypes> element can be used to extend instrumentation to apply to methods that are declared in extending classes.
...
AbstractTask.stop()because the method does not match the specified wildcard pattern of sta*.AbstractTask.stop(boolean)because the method does not match the specified wildcard pattern of sta*.RecoverableTaskAdapter.recover(RecoverableTaskContext)because the method does not match the specified wildcard pattern of sta*.RecoverableTaskAdapter.stop()because the method does not match the specified wildcard pattern of sta*.RecoverableTaskAdapter.stop(boolean)because the method does not match the specified wildcard pattern of sta*.
About instrumenting using annotations
Instrumentation can be applied to classes and interfaces that are annotated with a specific annotation
About instrumenting annotated classes and interfaces
The <annotation-name> element can be added to the <java-class> element to cause instrumentation to be applied to classes that are annotated with a specific annotation.
...
AbstractTask.startAbstractTask.stopRecoverableTaskAdapter.startRecoverableTaskAdapter.stop
About instrumenting annotated methods
The <annotation-name> element can be added to the <method> element to cause instrumentation to be applied to methods that are annotated with a specific annotation.
...
Based on these rules, custom-type instrumentation is applied to the following methods:
AbstractTask.start
About instrumenting annotated methods in implementing or inheriting classes
The <apply-to-subtypes> element can be added to the <method> element along with the <annotation-name> element, to cause classes that override or implement an annotated method to be instrumented.
...
AbstractTask.startRecoverableTaskAdapter.start
About instrumenting only classes that are not assignable to a class or interface
The < not-assignable-to> element can be added to the <java-class> element to prevent the rule from being applied to classes that are assignable to specific types.
...
Based on these rules, custom-type instrumentation is applied to the following methods:
AbstractTask.start
About instrumenting all calls from a method
Instrumentation can be applied to all calls from methods that match criteria specified in a <java-classes> element. This instrumenter configuration file causes instrumentation to be applied to all calls from the methods that match the <java-classes> element.
...
The rules that apply to the <java-classes> element that is documented in preceding sections are applied when it is used inside the <all-calls-from-method> element.
About instrumenting calls to methods
The <all-calls-to-method> element can be used to apply instrumentation to all calls to specific methods.
...
- The method signature must be enclosed in parentheses (“(“) and (“)”).
- The method signature must not contain spaces.
- A comma (“,”) must separate parameter types in the method signature.
- The method signature may include wildcards.
About preventing instrumentation for classes, methods, and calls to methods
Instrumentation can be prevented for specific packages and sub-packages, classes, methods, or calls to methods. The <ignore-config> element in instrumenter configuration files is used to illustrate how to prevent instrumentation from being applied to specific packages and sub-packages, classes, method, or calls to methods. See About instrumenter configuration file reference .
As with the <custom-config>, <all-calls-from-method>, <all-calls-to-method>, and <calls-from-method-to-method> elements, the <ignore-config> element can be placed in its own instrumenter configuration file. The examples should be considered to imply that the <ignore-config> element must be included in an instrumenter configuration file that contains other instrumentation directives.
About preventing instrumentation for all methods of classes in a package and sub-packages
The <java-classes> element can be used within an <ignore-config> element to prevent instrumentation from being applied to all methods of classes in a package and sub-packages using wildcards in the <class-name>.
...
RecoverableTaskAdapter.start()RecoverableTaskAdapter.stop()RecoverableTaskAdapter.stop(boolean)
About preventing instrumentation for methods of a class
The <java-classes> element can be used within an <ignore-config> element to prevent instrumentation from being applied to some or all methods of abstract or concrete classes, or to all methods of a class in a specific package and its sub-packages.
...
AbstractTask.start()AbstractTask.stop(boolean)RecoverableTaskAdapter.start()RecoverableTaskAdapter.stop(boolean)
About preventing instrumentation for calls from a method
The <all-calls-to-method> element can be used within an <ignore-config> element to prevent instrumentation from being applied to all calls to specific methods.
...
<?xml version'1.0'?>
<instrumenter-config>
<ignore-config>
<java-classes/>
<all-calls-to-method>
<methods>
<method>
<name> java.* </name>
</method>
</methods>
</all-calls-to-method>
</java-classes>
</ignore-config>
</instrumenter-config>
About preventing instrumentation for calls to a method
The <invocation-relationship> element can be used within an <ignore-config> element to prevent instrumentation from being applied to calls to specific methods from specific calling methods.
...
<?xml version='1.0'?>
<instrumenter-config>
<ignore-config>
<java-classes/>
<invocation-relationship>
<java-class>
<class-name> xmp.wfm.* </class-name>
<methods>
<method>
<name> stop </name>
<params> <params/>
</method>
</methods>
</java-class>
<invoked-method> java.*.*(int[]) </invoked-method>
</invocation-relationship>
</java-classes>
</ignore-config>
</instrumenter-config>
About instrumenting calls to EJB business method implementations
The J2EE specification does not require that an EJB implementation implement the remote interface directly. Application servers typically generate a skeleton that implements the remote interface directly and delegates calls to the EJB implementation.
Because there is no direct relationship between an EJB implementation and the remote interface, it is difficult to instrument the business methods of an EJB implementation without first identifying the remote interfaces and then manually instrumenting the methods.
About the Calls to EJB instrumentation feature
The Calls to EJB implementations instrumentation feature adds a configurable extension to the instrumenter to allow calls to EJB implementations to be instrumented.
...
| Property name | Multiplicity | Description |
|---|---|---|
logBeginMethodName | Optional | Identifies the logger method to call to report calls to EJB business methods. |
| logEndMethodName | Optional | Identifies the logger method to call to report calls to EJB business methods. |
| invocationType | Optional | Identifies how the logger events show up in Precise for J2EE. |
skeletonMarkerClass | Any Number | Identifies the classes that an EJB skeleton must extend. Only classes that extend a skeleton class or implement a skeleton interface are searched for calls to methods with matching name and signature. |
skeletonMarkerInterface | Any Number | Identifies the classes that an EJB skeleton must implement. Only classes that extend a skeleton class or implement a skeleton interface are searched for calls to methods with matching name and signature. |
implementationMarkerClass | Any Number | Identifies the classes that must be extended by calls with a matching name and signature. |
implementationMarkerInterface | Any Number | Identifies the classes that must be implemented by calls with a matching name and signature. |
Applying instrumentation using the "Calls to EJB" instrumentation feature
The following procedure describes how to apply instrumentation using the "Calls to EJB" instrumentation feature.
...
- Add the EJBImpl.xml file to the InstrumenterConfigList.xml file:
<instrumenter-config-list>
<config-file>
EJBImpl.xml
</config-file>
</instrumenter-config-list> - Restart the application server.
| Anchor | ||||
|---|---|---|---|---|
|
The purpose and schema of the various files that configure instrumentation for a monitored JVM is described in About the master configuration file, About the instrumenter configuration files, About the structure of instrumenter configuration files, and About common instrumenter configuration matching techniques.
Figure 18-1 Instrumenter Configuration
About the master configuration file
Instrumentation for each monitored JVM is configured from a master configuration file. The master configuration file, InstrumenterConfigList.xml, contains references to instrumenter configuration files that contain specific rules that are used to determine where and how to apply instrumentation to a monitored JVM.
...
${indepth.j2ee.home} expands to <i3_root>/products/j2ee${indepth.j2ee.server_id} expands to the JVM ID (with no sequence number)${indepth.j2ee.jvm_id} expands to the JVM ID (with a sequence number)
About the instrumenter configuration files
Instrumenter configuration files contain specific rules that are used to determine where and how to apply instrumentation. There are several default instrumenter configuration files located in the
...
| File name | Description |
|---|---|
| Logger.xml | Product configuration. |
| Planners.xml | Controls the order in which instrumentation is applied. |
| Heatseeker.xml | Adaptive instrumentation analysis results that are loaded at startup. This file is regenerated when adaptive instrumentation policies are run. |
| Ixp.xml | Instrumentation Explorer applied changes that are loaded at startup. This file is regenerated when you click the Instrumentation Explorer Apply Changes button. |
| Survey.xml | Adaptive survey instrumentation configuration. |
| SurveyConditional.xml | Adaptive conditional instrumentation configuration. |
| SurveySynchronization.xml | Adaptive synchronization instrumentation. |
| Servlet.xml | Default Java Servlet instrumentation configuration |
| GenericPortal.xml | Default Generic Portal-specific instrumentation configuration. Detects the portal and portlet configurations that implement javax.portlet.GenericPortlet. |
| GenericPortlet.xml | Default Generic Portlet-specific instrumentation configuration. Instruments the portlet lifecycle and action methods. |
| JSP.xml | Default JSP instrumentation configuration. |
| WebLogicJSP.xml | Default (BEA WebLogic™-specific) JSP instrumentation configuration. |
| WebSphereJSP.xml | Default (IBM® WebSphere®-specific) JSP instrumentation configuration. |
| WebLogicPortal.xml | Default BEA WebLogic Portal-specific instrumentation configuration. Detects the portal and portlet configuration. This file is populated when an application server portal version is selected in Precise Framework Installer. |
| WebLogicPortlet.xml | Default BEA WebLogic Portlet-specific instrumentation configuration. Instruments the detected portlets. This file is populated when an application server portal version is selected in Precise Framework Installer. |
| EJB.xml | Default EJB instrumentation configuration. Handles instrumentation of EJB stubs. |
| Ignore.xml | Default “ignored” instrumentation configuration. |
| CallsToJDBC.xml | Default “caller-side” JDBC instrumentation configuration. |
| OverInstrumentationProtection.xml | Over-instrumentation protection instrumentation configuration. |
| IndepthWeb.xml | Default instrumentation configuration that Precise for Web uses. This file is populated when Precise for Web is installed. |
| TACPeopleSoft.xml | Insight SmartLink for PeopleSoft instrumentation configuration. |
| TACWebApps.xml | Insight SmartLink for Web applications instrumentation configuration |
| Custom.xml | Contains an example instrumentation only. You should use this file as an example and edit this file. |
| CallsFromMethodToMethod.xml | Contains an example instrumentation only. You must edit this file. |
| LeakSeeker.xml | Configuration for Leak Seeker instrumentation. |
| WebLogicEJB.xml | Handles BEA WebLogic-specific EJB “lifecycle operation” instrumentation. |
| WebSphereEJB.xml | Handles IBM WebSphere-specific EJB “lifecycle operation” instrumentation. |
| OracleEJB.xml | Handles Oracle-specific EJB “lifecycle operation” instrumentation. |
| JNDI.xml | Default JNDI instrumentation configuration. |
| DataSource.xml | Default JDBC DataSource instrumentation configuration. |
| EJBBean.xml | Default EJB implementation instrumentation. |
| JTA.xml | Default Java Transaction instrumentation. |
| MessageDrivenEJB.xml | Default Message-Driven EJB instrumentation. |
| JMS.xml | Default Java Messaging Service instrumentation. |
| XML.xml | Default XML and XSL instrumentation. |
| Calls.xml | Template for configuring all calls to and all calls from methods. |
| EJBImpl.xml | Sample EJB implementation instrumentation. |
| Jolt.xml | Sample Jolt instrumentation. |
| MBeanImpl.xml | Sample MBean implementation instrumentation. |
| PeopleSoft.xml | Old PeopleSoft instrumentation. |
| SAP61.xml | SAP 6.1 instrumentation. |
| SmartuneInstrumentation.xml | Optional SmarTune instrumentation for servlet include and session analysis. |
About the structure of instrumenter configuration files
The instrumenter configuration files have the following general structure:
<?xml version='1.0'?>
<instrumenter-config>
<custom-config> </custom-config>
<all-calls-to-method> </all-calls-to-method>
<all-calls-from-method> </all-calls-from-method>
<calls-from-method-to-method> </calls-from-method-to-method>
<ignore-config> </ignore-config>
</instrumenter-config>
See About custom instrumentation configuration, About all calls to method instrumentation configuration, About all calls from method instrumentation configuration, About calls from method to method instrumentation configuration, and About ignore instrumentation configuration.
| Anchor | ||||
|---|---|---|---|---|
|
The <custom-config> element has the following structure:
<custom-config>
<java-classes>
<java-class> <!-- occurs 0 or more times -->
<class-name> class-or-interface-name </class-name>
<methods>
<method> <!-- occurs 0 or more times -->
<name> method-name </name>
<params> <!-- optional -->
<param> <!-- occurs 0 or more times -->parameter-type </param>
</params>
<capture-param-index> <!-- optional -->capture-parameter </capture-param-index>
</method>
</methods>
</java-class>
</java-classes>
</custom-config>
| Anchor | ||||
|---|---|---|---|---|
|
The <all-calls-to-method> element has the following structure:
<all-calls-to-method>
<methods>
<method> <!-- occurs 0 or more times -->
<name> method-name </name>
<params> <!-- optional -->
<param> <!-- occurs 0 or more times -->
parameter-type </param>
</params>
</method>
</methods>
</all-calls-to-method>
| Anchor | ||||
|---|---|---|---|---|
|
The <all-calls-from-method> element has this structure:
<all-calls-from-method>
<java-classes>
<java-class> <!-- occurs 0 or more times -->
<class-name> class-or-interface-name </class-name>
<methods>
<method> <!-- occurs 0 or more times -->
<name> method-name </name>
<params> <!-- optional -->
<param> <!-- occurs 0 or more times -->
parameter-type </param>
</params>
</method>
</methods>
</java-class>
</java-classes>
</all-calls-from-method>
| Anchor | ||||
|---|---|---|---|---|
|
The <calls-from-method-to-method> element has this structure:
<calls-from-method-to-method>
<invocation-relationship> <!-- occurs 0 or more times -->
<java-class>
<class-name> class-or-interface-name </class-name>
<methods>
<method> <!-- occurs 0 or more times -->
<name> method-name </name>
<params> <!-- optional -->
<param> <!-- occurs 0 or more times -->
parameter-type </param>
</params>
</method>
</methods>
</java-class>
<invoked-method> <!-- occurs 0 or more times -->
invoked-method-name </invoked-method>
</invocation-relationship>
</calls-from-method-to-method>
See About method signature matching.
| Anchor | ||||
|---|---|---|---|---|
|
Use the <ignore-config> element to configure rules that are used to determine when to prevent instrumentation from being applied to all methods in specifically matched classes or packages, to specifically matched methods, or to specifically matched calls to methods.
...
<java-classes>
<java-class> <!-- occurs 0 or more times -->
<class-name> class-or-interface-name </class-name>
<methods> <!-- optional -->
<method> <!-- occurs 0 or more times -->
<name> method-name </name>
<params> <!-- optional --> </params>
</method>
</methods>
</java-class>
</java-classes>
See About method signature matching.
For each method to be instrumented, the following rules are used to determine if instrumentation should not be applied to the method:
...
Wildcards are permitted in the class or interface name and method name. See About using the wildcard character *.
Use the <invocation-relationship> element to prevent instrumentation from being applied to specifically matched calls to methods from a specifically matched calling method. The <invocation-relationship> element has the following structure:
<invocation-relationship> <!-- occurs 0 or more times -->
<java-class>
<class-name> class-or-interface-name </class-name>
<methods>
<method> <!-- occurs 0 or more times -->
<name> method-name </name>
<params> <!-- optional -->
</params>
</method>
</methods>
</java-class>
<invoked-method> <!-- occurs 0 or more times -->
qualified-method-name </invoked-method>
</invocation-relationship>
See About method signature matching.
For each call to a method to be instrumented, the following rules are used to determine if instrumentation should not be applied to the method:
...
<all-calls-to-method>
<methods>
<method> <!-- occurs 0 or more times -->
<name> method-name </name>
<params> <!-- optional -->
</params>
</method>
</methods>
</invocation-relationship>
See About method signature matching.
The <name> element must represent a fully qualified method name. The portion of the <name> element after the last dot (“.”) is considered to be the method name, and the portion of the <name> element before the last dot is considered to be the class name. When you use wildcards, it is important to use a wildcard pattern that fits the scheme described. For example, the wildcards pattern *.* matches all methods of all classes.
About common instrumenter configuration matching techniques
Common instrumenter configuration matching techniques are method signature matching and using the wildcard character *.
| Anchor | ||||
|---|---|---|---|---|
|
The <params> element configures rules that are used to match method signatures for processing by the instrumenter. The <params> element has the following structure:
...
<invoked-method> com.acme.shared.comm.Connector.<init> (java.lang.String,int[][]) </invoked-method>
| Anchor | ||||
|---|---|---|---|---|
|
In addition to using specific names to reference items such as classes, interfaces, and methods, for instrumentation, you can also use the wildcard character * to instruct Precise for J2EE to instrument all classes, methods, or packages within the scope of the instruction.
...
| Info |
|---|
Use wildcard characters only when discovering the methods to instrument. Otherwise, it may result in instrumentation that does not yield meaningful performance metrics but introduces unwanted overhead. Do not implement wildcarded instrumentation in production environments. |
Including application server classes in Leak Seeker instrumentation
To obtain information on collections and arrays with the most elements, Leak Seeker instruments all user application classes but, by default, excludes application server classes. In special circumstances, you may want Leak Seeker to collect information on application server classes as well.
...