Page History
...
The Precise for J2EE Dashboard and Activity tabs include the findings area. This area displays specific problematic issues detected in the J2EE activity monitored by Precise for J2EE. The findings are displayed according to the definitions configured in the findings-config.xml file located in the registry file.
To modify the findings parameter settings1. Open the
- Open the
findings-config.xmlfile from the following path on the FocalPoint server:<i3_root>\products\i3fp\registry\products\j2ee\findings-config.xml
...
- Modify the desired configurable parameters. For more information regarding these parameters, see
...
...
- file.
...
- Run the relevant CLI command as it appears in step 3 of
...
- Instance registry or Cluster registry.
- Restart the Precise for J2EE FocalPoint.
The following table describes the configurable findings parameters.NOTE Configuring
| Info |
|---|
Configuring a parameter not mentioned in the Configurable parameters in the findings-config.xml file table may lead to errors in the displayed findings, or a general failure to load the findings. To configure such parameters, contact Precise Customer Support. |
Table 8-2 Configurable 2 Configurable parameters in the findings-config.xml fileAnchor Table82 Table82
| Parameter |
|---|
...
| Description |
|---|
| max-findings-to- |
...
| display | The maximum number of findings to be displayed in the user interface. Type: Integer Default value: 7 |
| timeout-in- |
...
| seconds | The time limit (in seconds) that the findings query will run. Type: Integer Default value: 20 |
...
enabled
| The finding will only be displayed if it is enabled. Type: Boolean Default value: true |
...
| tab | The finding will only be displayed in the specific tab (activity or dashboard) if it is enabled. Type: Boolean Default value: true |
| topN-to- |
...
| display | The maximum number of times a specific type of findings will be displayed (with different contexts). Type: Integer Default value: 2 |
...
thresholds | Each finding’s severity is calculated based on finding |
...
specific thresholds. Type: Integer |
| Anchor | ||||
|---|---|---|---|---|
|
Under certain circumstances, you may want to capture the HTTP servlet request query arguments and select Java method arguments. This section describes the configuration steps required to enable these features in Precise for J2EE.
A portal typically uses HTTP servlet request query string parameters to identify user services. Usually, very few servlets perform many different functions. The functions are differentiated by various query string parameter name=value pairs that are submitted in the URL. Additionally, URI paths may be independent of the query string parameters. Capturing the HTTP servlet request query string parameters to identify portal services is described in this section. In the following hyperlink, the substring s=VRTS is an HTTP query string parameter:•
http://finance.yahoo.com/q?s=VRTS
...
Application services, such as BEA’s Tuxedo, provide a Java API to select the desired service. Application programmers usually select the desired service by passing to the API an object, or string selector, describing their desired service. Capturing the Java parameters that are used to identify Tuxedo services is described in this section.
About getting started
You must first install Precise for J2EE and be able to collect and view application data in the Precise for J2EE user interface.
About capturing HTTP servlet query parameters
The configuration and interpretation of capturing HTTP query parameters is described in the following sections:• About
...
| Anchor | ||||
|---|---|---|---|---|
|
To enable HTTP Servlet Query parameter capture, add the following system property to your application server’s Java command line:
-Dindepth.j2ee.http.request.query.parameters=[options]
The value of the property (its [options]) controls which parameters are captured. A comma-separated list of parameter names is used to identify one or more specific parameters. A single asterisk is used to represent all parameters:.
In Precise for J2EE, the captured parameter names and values are appended to the URL of HTTP type invocations. A colon separates the method name from the parameter list. Each parameter is separated from its value by an equal (=) symbol. Commas separate parameter name/value pairs. Commas replace Ampersands. A maximum combined method name and parameter length of 128 characters is captured and displayed. See “About About using parameter capture” on page 109capture.
In addition, to print the entire HTTP query string and URI in the application server’s console window, add the following system property to your application server’s Java command line. This feature is useful for learning about the applications usage of specific query arguments:
-Dindepth.j2ee.verbose.parameters=true
In this example Java command line, we enable HTTP Servlet Query parameter capture for action and itemld parameters that are used in the Java PetStore application running on WebLogic 9 by adding the following:
...-Dindepth.j2ee.verbose.parameters=true
-Dindepth.j2ee.http.request.query.parameters=action,
...
itemid
...
In a PeopleSoft v8 demo example, we found this property value sufficient to capture interesting parameters that differentiated executions of each screen:
-Dindepth.j2ee.http.request
...
.parameters=FolderRef,Page,PortalActualURL,cmd
| Anchor | ||||
|---|---|---|---|---|
|
Typically, we start by using the following configuration:
-Dindepth.j2ee.http.request.
...
parameters=* and-Dindepth.j2ee.verbose.parameters=true
When we use this configuration all parameters on the console are printed, enabling us to inspect and learn which parameters are significant as we navigate through the application.
After we learn which parameters are important to us, we focus the capture on a few parameters by specifying them individually in a list, for example (see : -Dindepth.j2ee.http.request.query.parameters=param1,param2,param5,param7WARNING Capturing
| Warning |
|---|
Capturing all parameters can use significant system resources. As a result, capturing all parameters all the time is not recommended in production environments. |
Figure 8-1 HTTP 1 HTTP SRs using -dindepthDindepth.j2ee.http.request.query.parameters=param1,param2,param5,param7
About capturing Java method arguments
The following example illustrates the configuration and interpretation of captured Java method arguments. This example describes the instrumentation of Tuxedo service names from BEA's Jolt API as declared in the Jolt.xml instrumentation configuration file included in Precise for J2EE. To enable the Tuxedo service name capture, add the following element to your <i3_root>/products/i3fp/registry/clusters/j2ee/<cluster<cluster-name>name>/InstrumenterConfigList.x ml file:
<!--
BEA Jolt custom instrumentation
-->
<config-file>
Jolt.xml
</config-file>
To enable Java method argument capture, add a custom instrumentation element to an enabled instrumentation configuration file. The following example shows one of these elements that are configured for bea.jolt.JoltRemoteService. The example is taken from the Jolt.xml instrumentation configuration file that is distributed with Precise for J2EE. In this example, we display the Tuxedo service name whenever the bea.jolt.JoltRemoteService.call method is executed. A complication is that the Tuxedo service name is specified in the bea.jolt.JoltRemoteServiceconstructor (init) method and not passed directly to each execution of call.
Following is an example for the Java Method argument capture, custom instrumentation element, for bea.jolt.JoltRemoteService:
<instrumenter-config>
<custom-config>
<java-classes>
<java-class>
<class-name>
bea.jolt.JoltRemoteService
</class-name>
<methods>
<capture-method>
<name>
init
</name>
<capture-param-index>
0
</capture-param-index>
</capture-method>
<method>
<name>call</name>
</method>
</methods>
</java-class>
</java-classes>
</custom-config>
</instrumenter-config>
The <capture-method> element that is shown in this example identifies the Java method to be used to capture the data. The captured data is displayed in Precise for J2EE for methods specified by the <method> elements that share the same <java-class> element as the <capture-method> element. For the bea.jolt.JoltRemoteService.call case, since the Tuxedo service name is actually specified in the constructor (init) method, init is specified as the <capture-method> element.
The <capture-param-index> element defines the index count of the Java method argument to capture. The first argument is numbered zero, the second argument is numbered 1, and so on. The captured argument is converted to a string, using toString(), and appended (separated by a colon) to the method name of interest.
If you use the <capture-param-index> element without the <capture-method> element, the argument value of the index number that the <capture-param-index> element specifies is displayed following the associated method name. In other words, when <capture-method> is not used and <capture-param-index> is used, the argument that is specified by the <capture-param-index> element is both captured and appended to the method that is entered in the <name> element. For example, the following configuration appends the doProcess method’s first argument value to the doProcess method name that is displayed in Precise for J2EE.
<methods>
<method>
<name>doProcess</name>
<capture-param-index>0</capture-param-index>
</method>
</methods>
...