11 Auditing and Monitoring Java Projects

This chapter describes the auditing and monitoring capabilities of Oracle JDeveloper.

This chapter includes the following sections:

11.1 About Auditing and Monitoring Java Projects

Use the auditing and monitoring tools to analyze the performance of applications. An auditing feature analyzes Java code in JDeveloper for conformance to programming standards, and the HTTP Analyzer analyzes the HTTP traffic between projects to facilitate debugging an application.

Use the auditing and monitoring tools that JDeveloper provides to analyze the health and performance of your applications. These tools help you improve the quality of your code. You can use the JDeveloper auditing feature to analyze Java code for conformance to programming standards.

Auditing is concerned with programming standards, rather than syntactic correctness. You can audit code even when it is not compilable or executable.

You can use the HTTP Analyzer to facilitate debugging your application in terms of the HTTP traffic sent and received between your projects' web service clients and services and between your Java applications and web resources.

11.2 Auditing Java Projects

JDeveloper supports audit features such as qualitative tests for the presence or absence of some feature called rules, and the quantitative measurement of size or complexity through metrics. Use the listed methods to audit Java code.

Auditing is the static analysis of code for adherence to rules and metrics that define programming standards. A software code audit is a comprehensive analysis of source code in a programming project with the intent of discovering bugs, security breaches or violations of programming conventions.

A rule is a qualitative test for the presence or absence of some feature. For example, common Java coding style requires that class names be capitalized. A violation occurs when a rule is not adhered to.
A metric is a quantitative measurement of size or complexity. For example, a method that is too long, or covers too many cases should delegate some of its functionality to other methods. An over-threshold anomaly occurs when the specified upper bound is exceeded.

You can create and customize profiles, choose the rules to be used, and set parameters for individual rules. Browse the audit rules and metrics to learn more about them.

JDeveloper's audit and metrics features are extensible. Audit and metrics are two facets of a source code analysis and transformation framework that can be customized and extended. The public API for both audit and metrics is the oracle.jdeveloper.audit package.

To audit Java code:

Run the auditor on source files to produce an audit report. See How to Run Audit to Generate an Audit Report.
Use Code Assist to audit while editing. Code Assist enables background audits while you edit. Audit violations are highlighted as you edit. You can apply automated corrections.
Audit from the command line to produce an audit report. See Auditing Java Code from the Command Line.
Display the Issues window. The Issues Window is one of the JDeveloper features that helps you to audit your code. It displays audit violations in the document selected in the File List and provides information to help you resolve the issues.

An audit report displays rule violations and measurements organized as a tree. A row of the tree corresponds to either a construct or a violation, and includes any measured values for the construct or theoretical violation. A construct is a method, class, file, project, or workspace.

11.2.1 Understanding Audit Rules

Audit rules are static, qualitative, analyses of code. Use the tabulated properties to enable and configure the properties for individual rules in an auditing profile.

Audit rules are static, qualitative, analyses of code.

In an auditing profile, individual rules can be enabled and configured by setting their properties. When a code construct does not satisfy a rule, a rule violation is reported. Some rules define automatic fixes that you can choose to apply.

The rules contain the properties shown in Table 11-1.

Table 11-1 Rule Properties

Property	Description
Default fix	The fix that will be used for violations of this rule are when Apply Default Fix is applied to a construct.
Pattern	A regular expression used as a filter to find unconventional identifiers.
Severity	Use to sort rule violations in the audit report.
Visibility	A threshold based on the accessibility keyword. Violations will be reported only if they occur in classes or methods having at least the chosen visibility.

11.2.2 Understanding Audit Metrics

JDeveloper measures the metrics that are static, quantitative analyses of code. Configure metrics by setting a threshold, and enable and configure individual metrics within auditing profiles.

Audit metrics are static, quantitative analyses of code. In an auditing profile, individual metrics can be enabled and configured. Metrics are configured by setting a threshold: when a code construct exceeds the threshold, an over-threshold measurement is reported in the audit report.

JDeveloper measures the metrics shown in Table 11-2.

Table 11-2 Audit Metrics

Metric	Description
Depth of Inheritance Tree (DIT)	The depth of the inheritance tree of a class. By convention, j`ava.lang.Object` has DIT of 1, a class which directly extends j`ava.lang.Object` has DIT 2, and so on.
Number of Statements (NOS)	The size, in Java statements, of a method, class, or other construct.
Cyclomatic complexity (V(G))	The branching complexity of a method. Constructs which enclose methods, such as classes and projects, are assigned the maximum complexity measured for an enclosed method. Values above 10 are generally considered problematic.

11.2.3 Using the Auditing Tools

Auditing is the static evaluation of code against programming standards. Use auditing tools to view audit reports in the Log window, and to rectify violations and over-threshold measurements.

You can use auditing tools to view audit reports and to investigate and correct rule violations and over-threshold measurements. A new tab will be created in the Log window when auditing starts, and the audit report will be displayed in it.

Auditing is the static analysis of code for adherence to rules and metrics that define programming standards. Auditing finds defects that make code difficult to improve and maintain. The JDeveloper auditing tools help you find and fix such defects. Code can be audited even when it is not compilable or executable.

11.2.4 Using the Audit Window Report Panel

An audit report presents rule violations and metrics measurements as a tree organized into constructs: methods, classes, packages, files, projects, or workspaces. An audit profile with rules includes a Severity column, and an audit profile with metrics includes a measurements column.

An audit report is a set of rule violations and metrics measurements presented as a tree organized into constructs. A construct is a method, class, package, file, project, or workspace. If the audit profile includes rules, the table will have a Severity column that shows the designated severity of the constructs. If the audit profile includes metrics, the table will have an additional column for each metric showing the measurements for the constructs.

To sort the report by the contents of a column, click the column header. To reverse the sort order, click again.

11.2.5 Using the Audit Window Toolbar

Use the Log window toolbar for operations such as refresh, cancel, and export.

From the Log window toolbar you can perform the operations shown in Table 11-3.

Table 11-3 Audit Window Toolbar Icons

Icon	Name	Description
	Refresh	Click to rerun the audit on the same selection with the same profile.
	Cancel	Click to terminate a running audit. Note that this may give partial results.
	Export	Click to open the Export Results Dialog, from which you can save the report to a file. You may save the results in XML, HTML, or plain text.
	Expand All	Click to expand all the container nodes in the report, exposing all the rows.
	Collapse All	Click to collapse all the container nodes in the report, hiding all but the top-level constructs.
	Group By	Click to open the Group By dialog, from which you can specify the types of container constructs that will be shown. Grouping by constructs enables you to organize the results better, track defects and violations quickly, and analyze the results easily.
	Show Anomalies Only	Toggle the display of measurements that are within acceptable limits. The threshold is a settable property of metrics.
	Show Suppressed Issues	Toggle to show the suppression scheme issues.
	Fix	Choose a fix for a rule violation from the dropdown menu. For an individual rule violation, choose among the fixes defined for that violation's type. For a group construct, the only choice is Apply Default Fixes, which applies the default fix defined for its type, if any.
	Show Error Issues	Toggle to show just the number of errors in the selected file, or to list the errors in the file
	Show Warning Issues	Toggle to show just the number of warnings in the selected file, or to list the warnings in the file.
	Show Incomplete Issues	Toggle to show just the number of incomplete issues in the selected file, or to list the incomplete issues in the file.
	Show Advisory Issues	Toggle to show just the number of advisory issues in the selected file, or to list the advisory issues in the file.

11.2.6 Using the Audit Window Context Menu

In the Audit window, right-click one or more selected constructs or rule violations to open the context menu, and to use operations such as create, cancel, refresh, and export.

Select one or more constructs (container nodes) or rule violations (leaf nodes) and right-click to open the context menu. From the context menu you can perform the operations shown in Table 11-4 on the selected constructs or rule violations.

Table 11-4 Audit Window Context Menu Items

Name	Description
Create <construct>	Choose to apply the specified fix (constant, static field, instance field, variable, or method).
About <construct> Rule	Choose to display an explanation of the rule that applies to this rule violation.
Hide <Rule> Issues	Choose to remove all violations of the selected rule from the report.
Show Hidden Issues	Choose to restore all previously hidden issues.
Show Anomalies Only	Click to toggle the display of measurements that are within acceptable limits.
Show Error Issues	Click to toggle the display of the number of errors in the selected file, or to list the errors in the file
Show Warning Issues	Click to toggle the display of the number of warnings in the selected file, or to list the warnings in the file.
Show Incomplete Issues	Click to toggle the display of the number of incomplete issues in the selected file, or to list the incomplete issues in the file.
Show Advisory Issues	Click to toggle to show the display of the number of advisory issues in the selected file, or to list the advisory issues in the file.
Show Suppressed Issues(X)	Click to toggle the display of measurements that are within acceptable limits.
Cancel	Choose to terminate a running audit.
Refresh	Choose to rerun the audit.
Group By	Choose to open the Group By dialog, from which you can specify the types of container constructs that will be shown.
Expand All	Click to expand all the container nodes in the report, exposing all the rows.
Collapse All	Click to collapse all the container nodes in the report, hiding all but the top-level constructs.
Go to Source	Choose to open the source file at the point of the rule violation. If you wish, you can edit the file and correct the violation.
Export	Choose to open the Export Results Dialog, from which you can save the report to a file.

11.2.7 How to Audit Java Code in JDeveloper

Use the JDeveloper auditing tools to find and fix defects in code. Use the procedure to audit Java Code.

JDeveloper's auditing tools help you find and fix defects that make code difficult to improve and maintain. You can audit code even when it is not compilable or executable. The focus of an audit is defined by a profile, which is a set of audit rules and metrics. See Working with Audit Profile

To audit Java Code:

Create an Audit Profile that specifies the rules, code assists, and metrics used to analyze Java programs. In an Audit Profile, individual rules and metrics can be enabled and configured by setting their properties. When a code construct does not satisfy a rule, a rule violation is reported.
Run the Audit Report.
- From the main menu, choose Build > Audit <project>.
- You can also audit Java code from the command line by invoking ojaudit.exe, which is included in your JDeveloper installation.
Inspect the completed Audit Report for rule violation.

An Audit Report displays rule violations and measurements organized as a tree. A row of the tree corresponds to either a construct or a violation, and includes any measured values for the construct or theoretical violation. A construct is a method, class, file, project, or workspace.
Fix an audit rule violation manually by editing the source, or for some rules, by selecting an automated fix.
If you want to run the audit again, you can modify an audit profile by enabling or disabling rules, code assists, and metrics, or by changing their configuration.

You can save the finished audit report as an XML file or as a formatted HTML or text file. Formats are defined by XSL stylesheet files in the /jdev//audit/stylesheets directory (this directory is not created until audit is run). To create a custom format, adapt a copy of one of the predefined stylesheet files, and add it to the directory.

11.2.8 Auditing Java Code from the Command Line

Invoking the ojaudit.exe from the command line audits a workspace, a project, or a source file. Tabulated are the parameters you can use during an audit.

You can audit a workspace, a project, or a source file from the command line by invoking ojaudit.exe, which is included in your JDeveloper installation, in the jdev_install/jdeveloper/jdev/bin directory.

Synopsis

ojaudit option... file...

Table 11-5 contains the parameters you can use during the audit.

Table 11-5 Command Line Parameters

Parameter	Description
`file`	Specifies the workspace (`.jws`), project (`.jpr`), or source (`.java`) file to be audited.
-`classpath` `path`	Sets the class path for files to audit, if a project is not being audited.
`-disable` `name`	Disables the specified rule or metric in profile. To supply multiple values, repeat this option. This option requires the use of `-profile`.
`-enable` `name`	Enables the specified rule or metric in the profile. To supply multiple values, repeat this option.
`-encoding` `code`	Sets the character encoding for the report. If absent, the character encoding specified for the project is used (see the Compiler page of the project's Project Properties dialog).
`-fail` `severity`	Sets the issue severity that the Auditor will regard as failure.
`-fix`	Applies default fixes to the code. This option modifies source files.
`-help`	Prints help for the command help and exits.
`-listall`	Lists all audited files in the audit report including those that have no issues.
`-maxfilesize` `size`	Specifies the maximum file size, in Mb, to audit.
`-metric` `name`	Enables the specified metric.
`-nometric` `name`	Disables the specified metric. This option requires the use of `-profile` .
`-norule` `name`	Disables the specified audit rule. This option requires the use of `-profile`.
`-notitle`	Sets an empty audit report title.
`-output` `file`	Specifies the pathname of the output file. If omitted, output is written to standard output.
`-profile` `name`	(required) Specifies the profile to use. It is either one of the profiles defined in JDeveloper (as set in the Audit > Audit Profiles page of the Tools > Preferences dialog), or the path name of an exported Audit profile file. Case and whitespace are ignored when searching for a matching profile.
`-profilehelp`	Print defined profile names and exit.
`-profileoutput` `file`	Sets the output file for the merged profile.
-`project file`	The project context to use for parameters that are source files. If all parameters are projects or workspaces, this option is not required.
-`quiet`	Suppresses the copyright message.
-role name	Sets the active JDeveloper customization role.
-rule name	Enables the specified rule.
-seal	Seals the specified profiles. This option requires the use of `-profile` with an explicit path is also used.
-rulehelp	Prints the available rules and exits.
`-sourcepath` `path`	Set source path for files to audit, if a project is not being audited
`-style` `file`	The XSLT stylesheet to apply to the report. The name can either be a style sheet defined in JDeveloper, or a pathname to a style sheet file. If absent, the output will be an XML file. Case and whitespace are ignored when searching for a matching predefined stylesheet.
`-stylehelp`	Print defined style sheet names and exit.
`-title` `text`	The title to use for the report. If absent when `-untitled` is not specified, a default title will be used.
`-verbose`	Causes all execution messages to be displayed.
-`version`	Prints the command's version and exits.
`-workingset` `name`	Sets the working set for files to audit. This option requires the use of `-workspace`.
`-workingsethelp`	Prints the available working sets for the workspace and exits.
`-workspace` `file`	Sets the workspace context for files to audit.
`-xmlinput` `file`	Changes the format of an existing XML report. This option requires the use of `-style`.
`-xmloutput` `file`	Sets the output file as a plain XML report. This option requires the use of `-style`.
`@file`	Includes options and parameters from the audit file.

Note the following considerations:

Unless the file specified is a workspace or project, you must specify -project, -sourcepath, or -classpath.
If a project depends on other projects in the workspace, you must specify -workspace.
The options -profile and -style accept a name or a URL. Case and whitespace in the name are ignored.
The options -enable and -disable accept an ID or a label. Case and whitespace in the name are ignored.
The options -rule and -metric are synonymous of -enable. The options -norule and -nometric are synonymous of -disable.

11.2.9 Working with Audit Profile

An audit profile specifies the rules, code assists, and metrics that will be used to analyze Java code. Use a predefined profile, or modify a profile to create a custom profile.

An audit profile defines the focus of an audit by specifying the rules, code assists, and metrics that will be used to analyze Java code. You can activate and deactivate rules, code assists, and metrics for an audit profile from the Audit Profiles preferences page. While several profiles are predefined, you can create others by modifying an existing profile. You can modify an audit profile by enabling or disabling rules, code assists, and metrics, or by changing their configuration.

Certain audit profiles are used by default with some JDeveloper processes and features, as shown in Table 11-6.

Table 11-6 Audit Profile

Profile	Description
Code Assist Rules	Used by the Source Editor, Issues window, Application Overview, and File List.
Compile Rules	Used at the end of a compile when Audit While Compiling is selected in the Audit page of the Preferences dialog
Audit Rules	Used by the Source Editor, Issues window, Application Overview, and File List. This is the initial default for the Audit command. However, this is not permanent because the Audit dialog remembers whatever profile was last selected.
Javadoc Rules	Used by the Source Editor.
ADF Best Practice Rules	Used for ADF applications.

JDeveloper provides predefined profiles, each with different combinations of the available rules, code assists, and metrics:

ADF Best Practice Rules
All Metrics
All Rules
Audit Rules
Code Assist Rules
Compile Rules
Javadoc Rules

11.2.9.1 Create an Audit Profiler

Use the procedure to create an audit profile.

To create an audit profile:

From the main menu, choose Tools > Preferences.
Choose Audit and click Manage Profiles on the Audit page.
From the Profile drop-down list, choose a profile to copy.

As shown in the figure, the selected profile's property names and current values display in the right panel. A description of the selected item displays in the Explanation box. Its properties and settings display in the right pane.

Figure 11-1 Audit Profile Page

Description of "Figure 11-1 Audit Profile Page"
Select the rules, assists, and metrics to enable in the new profile.
Click Save As.
Enter a name for the new profile, and click Save.

Note:

Names are not case or space sensitive, though case and space are preserved. If the new name differs only in case or space from an existing name, a warning message appears to inform you of this.

The new profile name is shown in the in the Audit Profiles preferences page's Profile box.
Click OK.

11.2.9.2 Sealing a Profile

Saving the audit profile with the Sealed option selected in the Audit Profile page seals the profile so that only the selected rules are enabled when the audit profile is next loaded. Sealing the audit profile preserves the project environment, and prevents new audit issues from being introduced.

By saving the audit profile with the Sealed option selected in the Audit Profile page, you seal the current audit profile, which means that only the rules selected for that profile are enabled the next time that specific audit profile is loaded. Any new rules that are present since the profile was last saved are disabled (regardless of their default state). New rules can be introduced in a number of ways, such as when new extensions are installed when JDeveloper is updated. In the course of developing a project, sealing the audit profile preserves the project environment, preventing new audit issues from being introduced.

11.2.9.3 Disabling Suppression Schemes

A suppression scheme suppresses issues discovered through a project audit, and disabling suppression schemes reduces auditing time, and reduces Log output. Use the procedure to disable a suppression scheme.

A suppression scheme describes a scheme for suppressing issues (that is, audit violations) discovered through a project audit. When auditing a project, you can view suppression issues in the Audit Log window. You can enable (the default state) or disable suppression schemes from being audited through the Audit Profile dialog. Disabling suppression schemes can reduce auditing time and reduce output in the Log window.

To disable a suppression scheme:

From the main menu, choose Tools > Preferences.
Choose Audit and click Manage Profiles on the Audit page.
Click the Suppression Scheme tab. Uncheck the top-level node to disable all the suppression schemes of a specific category or expand the nodes to disable a specific scheme.

Check a box to enable a suppression scheme.
Click OK in the dialog.

11.2.10 How to Delete an Audit Profile

Although a predefined profile cannot be deleted, an existing audit profile, and any custom profile that was created with the Save As command can be deleted. Use the procedure to delete an existing audit profile.

You can delete an existing audit profile, but not a predefined profile. That any custom profile you created with the Save As command, you can delete.

To delete an existing audit profile:

From the main menu, choose Tools >Preferences.

The Preferences dialog opens.
Choose Audit and click Manage Profiles on the Audit page.
From the Profile drop-down list, choose a custom profile to be deleted.
From the More Actions drop-down list, choose Delete.

The profile is removed from the Profile box. Note that the predefined profiles provided by the IDE are grayed out and cannot be deleted.
Click OK.

11.2.11 How to Import or Export an Audit Profile

Importing or exporting audit profiles as XML files allows profile sharing, or maintaining a checked in profile used by ojaudit and a nightly build. Use the procedure to import or export an audit profile.

You can import or export audit profiles. This enables you to share profiles, for example, or to maintain a checked in profile used by ojaudit and a nightly build. Audit profiles are imported or exported as XML files.

To import or export an audit profile:

In the Tools menu, select Preferences to open the Preferences dialog.
Choose Audit and click Manage Profiles on the Audit page.
From the More Actions drop-down list, choose Import or Export, and select the profile you want to import or export.

11.2.12 How to Run Audit to Generate an Audit Report

Generate an audit report when you audit your Java programs so that rule violations and over-threshold measurements can be rectified. Use the procedure to generate an audit report.

When you audit your Java programs, you can generate an audit report. An audit report is a list of rule violations and over-threshold measurements. In the audit report, you can investigate these problems, and manually or automatically correct them.

To generate an audit report:

In the Applications window, select one or more applications, projects, or Java source files.

The Audit command also works for selections from other views, such as editors and the Structure window
From the main menu choose Build > Audit <target>, for example, Build > Audit helloWorld.java.
In the Audit <target> dialog, choose a profile to use in one of the two following ways:
- From the Profile drop-down list choose a profile to use.
- Click Edit to create or modify a profile.
Click Run.

An audit report appears in the Log window, and the audit begins. If you wish to stop the audit, click the stop icon in the log's toolbar.

11.2.13 How to Audit Unserializable Fields

Implementing the java.io.Serializable interface serializes an object making it possible to compress it into bytes so that it can be inflated later. Use the procedure to set audit rules.

An object is marked serializable by implementing the java.io.Serializable interface, which signifies that the object can be flattened into bytes and subsequently inflated in the future.

To turn off serialization on a field of an object, tag the field of the class of the object with the Java's transient keyword. If a class is marked as serializable, but contains unserializable fields that are not marked as transient, then the class is not serializable. You can run an audit to detect these unserializable fields.

To set audit rules:

From the main menu, choose Tools > Preferences > Audit > Manage Profiles.
Click the Rules tab and expand the nodes, Java SE > Java > Serialization.
Check Non-Serializable Field in Serializable Class.

A description of the rule is shown in right panel. You can set the default fix for the violation, the severity level of the violation, and the style of warning.
Click OK.

11.2.14 How to Audit Serializable Fields That Do Not Have serialVersionUID

The identifier, serialVersionUID enables versioning but even without this identifier, you can run an audit to flag the classes that implement java.io.Serializable. Use the procedure to set audit rules.

There is an identifier called serialVersionUID that enables versioning. You can run an audit that flags all classes that implement java.io.Serializable but do not also have the serialVersionUID.

To set audit rules:

From the main menu, choose Tools > Preferences > Audit > Manage Profiles.
Click the Rules tab and expand the nodes, Java SE > Java > Serialization.
Check Missing Serialization UID.

A description of the rule is shown in right panel. You can set the default fix for the violation, the severity level of the violation, and the style of warning.
Click OK.

11.2.15 Viewing an Audit Report

JDeveloper generates a report of all audit rule violations and over-threshold measurements so that they can be corrected. Use the procedures to refresh an audit report, and to inspect an audit rule violation.

JDeveloper generates a report of all audit rule violations. Use the audit report to investigate and correct rule violations and over-threshold measurements. As shown in the figure, audit reports are displayed as tabbed panes of the Log window. In this window, you can choose a fix for a rule violation from a drop-down menu. For an individual rule violation, choose among the fixes defined for that violation's type.

Figure 11-2 Audit Report

Description of "Figure 11-2 Audit Report"

Use refresh to rerun an audit using the same profile. You may wish to perform a refresh after you have made changes and fixes to your code.

To refresh an audit report:

Click in the Log Window toolbar, or right-click and choose Refresh.

The Export Audit Results dialog clears, and a new audit begins. If you want to stop the audit, click in the Log's toolbar.

To inspect an audit rule violation:

In the audit report, select the construct you want to view.
Right-click and choose Go to Source, or double-click the construct.

An editor for the source file opens with the cursor positioned at the location of the rule violation or the code element measured
Right-click on a violation or anomaly, and select About violation Rule to learn more about the rule that has been violated. A dialog describing the rules displays, as shown in the figure below.

Figure 11-3 About Rule Dialog

Description of "Figure 11-3 About Rule Dialog"

You can rearrange the audit report columns into left or right positions.

To organize audit report columns:

Drag the column headers left or right to your preferred position.

11.2.16 How to Organize Audit Report Rows

An Audit report is organized as a tree with each row corresponding to a construct or a violation that includes measured values or a theoretical violation. Use the procedure to organize audit report rows.

Audit report rows are rule violations or measurements, or groups of violations and measurements. The report is organized as a tree. A row of the tree corresponds to either a construct or a violation, and includes any measured values for the construct or a theoretical violation. A construct is a method, class, file, package directory, project, or workspace.

You can choose the constructs that are shown in the report.

To organize audit report rows:

Click the Group By icon in the Log window toolbar.
Select the constructs you want to see.
Click OK.
Click a column header to sort rows by that column.

To reverse the sort order, click again.

11.2.17 Using Filters with Reports

Patterns in filters determine which classes pass through the filters, and specifying filters by package names, class names, or both prunes the set of Java classes whose violations are displayed. Tabulated are the filters that you can specify.

You specify filters to prune the set of Java classes whose violations are shown. You can filter by package names, class names, or both. A filter consists of one or more patterns separated by commas.

A pattern can contain the following special characters:

* matches any number of characters
? matches any single character
! at the beginning of a pattern denotes an exclusion pattern

The set of classes that passes a filter is determined by considering the patterns in order. A non-exclusion pattern adds all classes that match the pattern to the set, an exclusion pattern removes all classes that match the pattern from the set. Table 11-7 contains the filters you can specify

Table 11-7 Filters

Name	Description
Package	Enter filter patterns that will apply to all but the last element of fully qualified class names. If this field is empty it has no effect.
File	Enter filter patterns that will apply only to the last element of fully qualified class names. If this field is empty it has no effect.
Apply	Click to apply the given Package and File filters to the report's rows.
Clear	Click to erase the Package and File filters, and to restore the report's rows.

11.2.17.1 How to Filter Audit Report Rows

Use the procedure to filter audit report rows. Enter the sequence of patterns to be applied to all but the last element of FQCNs in the Package field and enter the sequence of patterns for the last element in Field.

To filter audit report rows:

In the Package field of the audit log window, enter a sequence of patterns that will apply to all but the last element of fully-qualified class names. You can leave this box empty if you specify a File filter.
In the File field, enter a sequence of patterns that will apply only to the last element of fully-qualified class names. You can leave this box empty if you specify a Package filter.
Click Apply.

The report redisplays to show only the selected rows.
Click Clear to delete text from the Package and File boxes.

11.2.18 How to Save an Audit Report

Save audit reports as XML files or as formatted HTML or text files. Use the step to save an audit report.

You can save an audit report as an XML file or as a formatted HTML or text file. Formats are defined by XSL stylesheet files in the directory, jdev_install/jdev/system/audit/stylesheets (this directory is not created until audit is run). To create a custom format, adapt a copy of one of the predefined stylesheet files, and add it to the directory.

To save an audit report:

Click in the Log Window toolbar, or right-click and choose Export.

The Export Audit Results dialog display. Choose a title, format, and destination for the report, and click OK.

11.2.19 How to Fix an Audit Rule Violation

Edit source code to fix audit rule violations manually, or select an automated fix; use defined fixes for individual rules; and use Apply Default Fixes for a group construct. Use the procedures to fix an audit rule violation manually, and to apply an automated fix to an audit rule violation.

You can fix an audit rule violation manually by editing the source, or for some rules, by selecting an automated fix. For an individual rule violation, choose among the fixes defined for that violation's type. For a group construct, the only choice is Apply Default Fixes, which applies the default fix defined for its type, if any.

To fix an audit rule violation manually:

In the audit report, select the rule violation (a leaf node in the Constructs tree).
Right-click and choose Go to Source.

An editor for the source file opens with the cursor positioned at the location of the rule violation.
Edit the code to correct the cause of the violation.

To apply an automated fix to an audit rule violation:

In the audit report, select the rule violation (a leaf node in the Constructs tree).
Right-click, and choose an Apply <Rule> Fix menu item, if any.

or

Click in the Log window toolbar, and choose one of Apply <Rule> Fix menu items.

11.2.20 How to Fix a Construct's Audit Rule Violations

Constructs that have a Default Fix property with a value other than None will have automated fixes applied to each rule violation. Use the procedure to fix audit rule violations of a construct.

You can apply automated fixes to all the rule violations in a construct. Default fixes will be applied to each rule violation in the construct that has a Default Fix property with a value other than None.

To fix a construct's audit rule violations:

In the audit report, select the construct (a container node in the Constructs tree).
You can apply default fixes in one of the two following ways:
- Right-click, and choose Apply Default Fixes.
- Click in the Log window toolbar, and choose Apply Default Values.

11.2.21 How to Hide Audit Rule Violations

Hiding all violations of a particular rule in the audit report makes the report more readable. Use the procedures to hide audit rule violations, and to restore hidden audit rule violations.

You can suppress the display of all the rule violations of a given type in the audit report. This may make the report easier to read, since it hides all violations of a particular rule. It is not possible to suppress individual rule violations.

To hide audit rule violations:

In the audit report, select a rule violation (a leaf node in the Constructs tree).
Right-click, and choose Hide rule Issues.

All of the violations of the audit rule are removed from the audit report. The removed rules are not tallied in their parent construct's summaries. Empty constructs are removed if Show Over Threshold Only is enabled. If not, just the violations are removed.

To restore hidden audit rule violations:

In the audit report, right-click to open the context menu.
Choose Show Hidden Issues.

All of the previously hidden rule violations are restored to the audit report.

11.2.22 How to Hide Audit Report Measurements

Set the focus of metrics reports on over-threshold measurements by hiding other measurements. Use the Show Anomalies Only option in the Log window to show only over-threshold measurements.

Metrics reports display measurements for the constructs in the analyzed code. You can focus the report on over-threshold measurements by hiding the others. The threshold is a settable property of metrics.

To show only over-threshold measurements:

In the Log window toolbar, click the over Show Anomalies Only icon. Click again to show all measurements.

Removed measurements are not tallied in their parent construct's summaries. Empty constructs are removed if Show Over Threshold Only is enabled. If not, just the violations are removed.

11.3 Monitoring HTTP Using the HTTP Analyzer

The HTTP Analyzer acts as a proxy between the code in JDeveloper and the HTTP resource, and thus helps in debugging an application.

The HTTP Analyzer allows you to monitor HTTP traffic, for example, to:

Monitor request/response traffic between a web service client and the service.
Monitor HTTP requests between Java applications and web resources.

The HTTP Analyzer acts as a proxy between code in JDeveloper and the HTTP resource that the code is communicating with, and helps you to debug your application in terms of the HTTP traffic sent and received.

When you run the HTTP Analyzer, there are a number of windows that provide information for you.

11.3.1 How to Use the Log Window

The HTTP Analyzer Log window opens when you open the HTTP Analyzer from the Tools menu. Use the tools on the HTTP Analyzer Log Window Toolbar to reorder or group messages in the Log window.

When you open the HTTP Analyzer from the Tools menu, the HTTP Analyzer Log window opens, illustrated in the figure. By default its position is at the bottom center of JDeveloper, alongside the other log windows.

Figure 11-4 HTTP Analyzer Log Window

Description of "Figure 11-4 HTTP Analyzer Log Window"

When HTTP Analyzer runs, it outputs request/response messages to the HTTP Analyzer log window. You can group and reorder the messages:

To reorder the messages, select the Sequence tab, then sort using the column headers (click on the header to sort, double-click to secondary sort).
To group messages, click the Correlation tab.
To change the order of columns, grab the column header and drag it to its new position.

Table 11-8 HTTP Analyzer Log Window Toolbar Icons

Icon	Name	Function
	Analyzer Preferences	Click to open the HTTP Analyzer Preferences dialog where you can specify a new listener port, or change the default proxy. An alternative way to open this dialog is to choose Tools > Preferences, and then navigate to the HTTP Analyzer page.
	Create New Request	Click to open the HTTP Analyzer Test window, where you enter payload details, and edit and resend messages.
	Start HTTP Analyzer	Click to start the HTTP Analyzer running. The monitor runs in the background, and only stops when you click Stop or exit JDeveloper. If you have more than one listener defined clicking this button starts them all. To start just one listener, click the down arrow and select the listener to start.
	Stop HTTP Analyzer	Click to stop the HTTP Analyzer running. If you have more than one listener running, clicking this button stops them all. To stop just one listener click the down arrow and select the listener to stop.
	Send Request	Click to resend a request when you have changed the content of a request. The changed request is sent and you can see any changes in the response that is returned.
	Open WS-I log file	Click to open the Select WS-I Log File to Upload dialog, where you can navigate to an existing WS-I log file. See Monitoring and Analyzing Web Services.
	Save Packet Data	Click to save the contents of the HTTP Analyzer Log Window to a file.
	WS-I Analyze	Click to invoke the WS-I Analyze wizard which allows you to examine a web service at packet level. See Monitoring and Analyzing Web Services.
	Select All	Click to select all the entries in the HTTP Analyzer Log Window.
	Deselect All	Click to deselect all the entries in the HTTP Analyzer.
	Clear Selected History (Delete)	Click to clear the entries in the HTTP Analyzer.

11.3.2 How to Use the Test Window

Use Test Web Service from the context menu of a web service container in the Applications window to see details of a request or response in a test window. See messages in the SOAP format or as HTTP code.

An empty HTTP Analyzer test window appears when you click the Create New Request button in the HTTP Analyzer Log window. A test window showing details of the request/response opens when you choose Test Web Service from the context menu of a web service container in the Applications window, or when you double-click a line in the HTTP Analyzer Log Window, illustrated in the figure below. By default, its position is in the center of JDeveloper, in the same place that the source editor appears.

Figure 11-5 HTTP Analyzer Test Window

Description of "Figure 11-5 HTTP Analyzer Test Window"

The test window allows you examine the headers and parameters of a message. You can test the service by entering a parameter that is appropriate and clicking Send Request.

The tabs along the bottom of the test window allow you choose how you see the content of the message. You can choose to see the message as:

The SOAP structure, illustrated in the figure above.

The HTTP code, for example:

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://annotation/">
    <env:Header/>
    <env:Body>
        <ns1:getDeptInfo>
            <arg0/>
        </ns1:getDeptInfo>
    </env:Body>
</env:Envelope>

The hex content of the message, for example:

[000..015] 3C 3F 78 6D 6C 20 ... 3D 22 31    <?xml version="1
[016..031] 2E 30 22 20 65 6E ... 22 55 54    .0" encoding="UT
[032..047] 46 2D 38 22 3F 3E ... 6E 76 65    F-8"?> <env:Enve
[048..063] 6C 6F 70 65 20 78 ... 76 3D 22    lope xmlns:env="

The raw message, for example:

POST http://localhost:7101/WebService-Annotation-context-root/MyCompanyPort HTTP/1.1
SOAPAction: ""
Content-Type: text/xml; charset=UTF-8
Host: localhost:7101
Content-Length: 277
 
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://annotation/">
    <env:Header/>
    <env:Body>
        <ns1:getDeptInfo>
            <arg0/>
        </ns1:getDeptInfo>
    </env:Body>
</env:Envelope>

11.3.3 How to Use the Instances Window

Open the HTTP Analyzer Instances window using HTTP Analyzer from the Tools menu to view instances of the HTTP Analyzer that are running, or had been running. The window allows you to start and stop an instance.

When you open the HTTP Analyzer from the Tools menu, the HTTP Analyzer Instances window appears. By default, its position is at the bottom center of JDeveloper, as a tab alongside the HTTP Analyzer log window. This window provides information about the instances of the HTTP Analyzer that are currently running, or that were running and have been stopped. The instance is identified by the host and port, and any rules are identified. You can start and stop the instance from this window.

Figure 11-6 HTTP Analyzer Instances Window

Description of "Figure 11-6 HTTP Analyzer Instances Window"

You create a new instance in the HTTP Analyzer page of the Preferences dialog, which opens when you click .

Table 11-9 HTTP Analyzer Instances Window Toolbar Icons

Icon	Name	Function
	Analyzer Preferences	Click to open the HTTP Analyzer page of the Preferences dialog where you can specify a new listener port, or change the default proxy.
	Create New Request	Click to open a new instance of the HTTP Analyzer Test window, where you enter payload details, and edit and resend messages.
	Start HTTP Analyzer	Click to start the HTTP Analyzer running. The monitor runs in the background, and only stops when you click Stop or exit JDeveloper. If you have more than one listener defined clicking this button starts them all. To start just one listener, click the down arrow and select the listener to start.
	Stop HTTP Analyzer	Click to stop the HTTP Analyzer running. If you have more than one listener running, clicking this button stops them all. To stop just one listener click the down arrow and select the listener to stop.

11.3.4 What Happens When You Run the HTTP Analyzer

Run the HTTP Analyzer to send the traffic of all Java processes and application server activity with JDeveloper by means of the HTTP Analyzer, using the proxy settings in the HTTP Analyzer page of the Preferences dialog.

When you start the HTTP Analyzer, all Java processes and application server activity with JDeveloper will send their traffic via the HTTP Analyzer, using the proxy settings in the HTTP Analyzer page of the Preferences dialog, which opens when you click the Start HTTP Analyzer button in the Instance or Log window. By default, the HTTP Analyzer uses a single proxy on an analyzer instance (the default is 8099), but you can add additional proxies of your own if you need to.

Each analyzer instance can have a set of rules to determine behavior, for example, to redirect requests to a different host/URL, or to emulate a web service.

11.3.5 How to Specify HTTP Analyzer Settings

Specify HTTP analyzer settings such as a different host and port number. Use the procedure to set HTTP Analyzer preferences.

By default, the HTTP Analyzer uses a single proxy on an analyzer instance (the default is 8099), but you can add additional proxies of your own if you need to.

To set HTTP Analyzer preferences:

Open the HTTP Analyzer preferences dialog by doing one of the following:
- Click the Start HTTP Analyzer button in the HTTP Analyzer Instances window or Log window.
- Choose Tools > Preferences to open the Preferences dialog, and navigating to the HTTP Analyzer page.
For more information at any time, press F1 or click Help from the HTTP Analyzer preferences dialog.
Make the changes you want to the HTTP Analyzer instance. For example, to use a different host and port number, open the Proxy Settings dialog by clicking Configure Proxy.

11.3.6 How to Use Multiple Instances

When multiple instances of the HTTP Analyzer run, each instance uses a different host and port combination, and the HTTP Analyzer Instances window displays instance summaries. Use the procedure to add an additional HTTP Analyzer Instance.

You can have more than one instance of HTTP Analyzer running. Each will use a different host and port combination, and you can see a summary of them in the HTTP Analyzer Instances window.

To add an additional HTTP Analyzer Instance:

Open the HTTP Analyzer preferences dialog by doing one of the following:
- Click the Analyzer Preferences button in the HTTP Analyzer Instances window or Log window.
- Choose Tools > Preferences to open the Preferences dialog, and navigating to the HTTP Analyzer page.
For more information at any time, press F1 or click Help from the HTTP Analyzer preferences dialog.
To create a new HTTP Analyzer instance, that is a new listener, click Add. The new listener is listed and selected by default for you to change any of the values.

11.3.7 How to Configure External Web Browsers

Use external web browsers to route messages through the HTTP Analyzer to view traffic between a web browser and a client. Use the procedure to configure a Firefox profile for the HTTP Analyzer.

You can use external web browsers to route messages through the HTTP Analyzer so that you can see the traffic between the web browser and client. This section describes how you can use a profile in Firefox so that when you start the HTTP Analyzer and run an HTML or JSP or JSF page from within JDeveloper, a new instance of Firefox using the Debugger profile is started.

Note:

The steps below use the command firefox, which is correct for Linux. If you are using Windows, use firefox.exe.

To configure a Firefox profile for the HTTP Analyzer:

First you create a new Firefox profile. By default, starting Firefox from the command line opens a window on your currently open instance of Firefox, so you need to use -no-remote to create a separately configured instance Run the following from the command line
```
firefox -no-remote -CreateProfile Debugging
```
Start Firefox using this profile
```
firefox -no-remote -P Debugging
```
Next you configure JDeveloper to start this version of Firefox. From the main menu, choose Tools > Preferences.
In the Preferences dialog, select the Web Browser and Proxy node. For more information, press F1 or click Help from within the dialog page.
In the Browser Command Line, enter or browse to the correct location, and enter firefox -no-remote -P Debugging. JDeveloper underlines this in red, and when you close the dialog you will see a Command Line Validation Error warning which you can safely ignore.
Click OK. When you start the HTTP Analyzer and run an HTML or JSP or JSF page from within JDeveloper, a new instance of Firefox using the Debugger profile is started.

Click OK. When you start the HTTP Analyzer and run an HTML or JSP or JSF page from within JDeveloper, a new instance of Firefox using the Debugger profile is started.

11.3.8 Using SSL with the HTTP Analyzer

JDeveloper secures the HTTP Analyzer with the preconfigured HTTPS Credential, the HTTPS Keystore to encrypt HTTP messages, username tokens for basic authentication, PKI X509 certificates for SSO, Secure Token Service to manage security tokens over HTTPS, the OAuth protocol for authentication, and jps-config.xml to access JRF web services.

You can use the HTTP Analyzer with secured services or applications, for example, web services secured by policies. JDeveloper comes with a set of preconfigured credentials, HTTPS Credential, which is always present. You cannot delete or edit HTTPS Credential, but you can copy it to create a new credential of the same type.

When you run the service or application the analyzer uses the supplied credentials for perform the appropriate action.

The HTTP Analyzer can use the following types of credential:

HTTPS Keystore

HTTPS encrypts an HTTP message prior to transmission and decrypts it upon arrival. It uses a public key certificate signed by a trusted certificate authority. When the integrated application server is first started, it generates a DemoIdentity that is unique to your machine, and the key in it is used to set up the HTTPS channel.

The client keystore identity is used for configuring HTTPS. The server keystore identity is used when the HTTP Analyzer is acting as a server; it is not used when connecting to a remote server.

For information about keystores and keystore providers, see Configuring Keystores. When the default credential HTTPS Keystore is selected, you need to specify the keystores that JDeveloper and the HTTP Analyzer should use when handling HTTPS traffic. Two keystores are required to run the HTTP Analyzer:

The client keystore, containing the certificates of all the hosts to be trusted by JDeveloper and the Analyzer (client trust) when it makes onward connections.
The server keystore, containing a key that the Analyzer can use to authenticate itself to calling clients (server keystore).

The client keystore is only required when mutual authentication is required.

You can create extra HTTPS keystores in addition to the default one provided by JDeveloper.

Username Token

Username token is a way of carrying basic authentication information. You supply a username/password to provide authentication.

X509 Certificates

X509 is a PKI standard for single sign-on, where certificates are used to provide identity, and to sign and encrypt messages. You enter details of an X509 certificate. When you supply a valid keystore and the password for the keystore, the client key aliases are populated.

If JDeveloper has any problems finding and opening the keystore, error messages will be displayed.

STS Configuration

A Secure Token Service (STS) is a web service that issues and manages security tokens over HTTPS. You enter the Security Token Server provider URL and optionally a policy URL.

Note:

The client truststore must contain the server public key, otherwise when the HTTP Analyzer requests the SAML token it will fail.

OAuth Details

OAuth is an open authentication protocol that allows users to approve application to act on their behalf without sharing their password. You can test resources protected by OAuth protocol security using a valid OAuth credential, for example, to test resources that use Twitter feeds.

Note:

To access resources owned by users with a service provider you must first register with the service provider.

Import from JPS Config

Use to test JRF web services. jps-config.xml contains the security information that the HTTP Analyzer needs to access the service.

You can import of data from jps-config.xml into a credential record. You provide the location of jps-config.xml and enter the name of a CSF key and JDeveloper creates a credential record with the necessary data read from jps-config.xml and from the underlying wallet file.

Data imported from jps-config.xml is populated in the X509 Certificates tab and in the Username Token tab.

Once saved, the credential record can be used repeatedly in the HTTP Analyzer and during web service proxy generation as the source for the keystore, keys and other required data.

11.3.8.1 How to Use SSL with the HTTP Analyzer

JDeveloper comes with a set of HTTPS Keystore credentials called HTTPS Credential. You can:

Configure the client keystore for HTTPS Credential if mutual authentication is required.
Create a new credential of one of the supported types.
Create a new credential based on an existing credential.
Delete a credential. Note that you cannot delete HTTPS Credential.

To configure credentials:

From the main menu, choose Tools > Preferences.
In the Preferences dialog, select the Credentials node. For more information, press F1 or click Help from within the dialog page.
Make the appropriate changes:
- Add client information for HTTPS Credential by choosing the HTTPS Keystore tab.
- Add a new credential by clicking and selecting the appropriate tab.
- Create a new credential based on an existing credential by clicking . A new credential is created of the same type and with the same values with a default name of Credential_n incremented by 1.
- Delete a credential by selecting it from the list and clicking . Note that you cannot delete HTTPS Credential.

11.3.9 How to Run the HTTP Analyzer

JDeveloper provides a set of HTTPS Keystore credentials called HTTPS Credential to configure a client keystore, create, and delete credentials. Use the procedure to configure credentials.

The HTTP Analyzer allows you to view the content of request and response HTTP messages.

To monitor HTTP packets:

Open the HTTP Analyzer by choosing Tools > HTTP Analyzer. The HTTP Analyzer docked window opens.
Start the HTTP Analyzer by clicking the Start HTTP Analyzer button. By default, this starts the listener on your localhost's hostname on port 8098. You can add new listeners, and use different hosts and ports, configure HTTPS, or set up rules to determine how the analyzer works.
Run the class, application, web service and so on that you want to analyze in the usual way.

Each request and response packet is listed in the HTTP Analyzer Log window, and detailed in the HTTP Analyzer Test Window.

If you are using the HTTP Analyzer to examine how a web service developed in JDeveloper works, the HTTP Analyzer starts automatically when you choose Test Web Service from the context menu of the web service in the Applications window.

11.3.10 How to Debug Web Pages Using the HTTP Analyzer

Using the HTTP Analyzer to debug Web pages allows you a direct view of the to-and-fro web traffic. Use the procedure to debug Web pages using the HTTP Analyzer.

You can use the HTTP Analyzer when you are debugging Web pages, such as HTML, JSP, or JSF pages. This allows you to directly examine the traffic that is sent back and forth to the browse.

To debug Web pages using the HTTP Analyzer:

Configure a browser to route messages through the HTTP Analyzer so that you can see the traffic between the web browser and client.
Start the HTTP Analyzer running.
Run the class, application, or Web page that you want to analyze in the usual way.

Each request and response packet is listed in the HTTP Analyzer Log window, and detailed in the HTTP Analyzer Test Window.

11.3.11 How to Edit and Resend HTTP Requests

If you need to resend a HTTP request, edit the message and verify the changes in the message response. Use the procedures to send a request, and to edit and resend a request.

You can edit the contents of a HTTP request and resend it. You can then examine the response to see whether the changes you expect have occurred.

To send a request:

In the Request pane of the HTTP Analyzer Test window, enter parameter values.
Click the Send Request button.
The processed value is returned in the Response pane.

To edit and resend a request:

In the Request pane of the HTTP Analyzer Test window, click Copy Request. This opens a new test window, where you can enter a new parameter to send.

Alternatively, you can open a new test window by double-clicking a line in the HTTP Analyzer Log window.

11.3.12 How to Use Rules to Determine Behavior

Set rules such as Pass Through Rule, Forward Rule, URL Substitution Rule, and Tape Rule so that the rules determine how the HTTP Analyzer runs.

You can set rules so that the HTTP Analyzer runs using behavior determined by those rules. You can set more than one rule in an HTTP Analyzer instance. If a service's URL matches a rule, the rule is applied. If not, the next rule in the list is checked. If the service does not match any of the rules the client returns an error. For this reason, you should always use a Pass Through rule with a blank filter (which just passes the request through) as the last rule in a list to catch any messages not caught by the preceding rules.

The types of rule available are:

Pass Through Rule
Forward Rule
URL Substitution Rule
Tape Rule

11.3.12.1 Using the Pass Through Rule

The Pass Through rule passes a request to the service if the URL filter provides a match. Define Pass Through Rules in the Rule Settings dialog which displays two default rules.

The Pass Through simply passes a request on to the service if the URL filter matches. When you first open the Rule Settings dialog, two Pass Through Rules are defined:

The first has a URL filter of http://localhost:631 to ignore print service requests.
The second has a blank URL filter, and it just which just passes the request to the original service. This rule should normally be moved to end of the list if new rules are added.

11.3.12.2 Using the Forward Rule

The Forward rule is used to intercept all URLs matched by the filter and it forwards the request on to a single URL.

11.3.12.3 Using the URL Substitution Rule

Use the URL Substitution rule to replace parts of URL ranges so that you can re-host services.

The URL Substitution rule allows you to re-host services by replacing parts of URL ranges. For example, you can replace the machine name when moving between the integrated application server and Oracle WebLogic Server.

11.3.12.4 Using the Tape Rule

Run the HTTP Analyzer with the tape rule in the simulator mode using the standard WS-I log file as the input to the rule. Use the procedure to test a web service client that is developed to run against an external web service.

The tape rule allows you to run the HTTP Analyzer in simulator mode, where a standard WS-I log file is the input to the rule. When you set up a tape rule, there are powerful options that you can use:

Loop Tape, which allows you to run the tape again and again.
Skip to matching URL and method, which only returns if it finds a matching URL and HTTP request method. This means that you can have a WSDL and an endpoint request in the same tape rule.
Correct header date and Correct Content Size, which allow you change the header date and content size of the message to current values so that the request does not fail.

An example of using a tape rule would be to test a web service client developed to run against an external web service.

To test a web service client developed to run against an external web service:

Create the client to the external web service.
Run the client against the web service with the HTTP Analyzer running, and save the results as a WS-I log file.

You can edit the WS-I file to change the values returned to the client.
In the HTTP Analyzer page of the Preferences dialog, create a tape rule.

Ensure that it is above the blank Pass Through rule in the list of rules.
In the Rule Settings dialog, use the path of the WS-I file as the Tape path in the Rule Settings dialog.
When you rerun the client, it runs against the entries in the WS-I file instead of against the external web service.

There are other options that allow you to:
- Correct the time and size of the entries in the WS-I log file so the message returned to the client is correct.
- Loop the tape so that it runs more than once.
- Skip to a matching URL and HTTP request method, so that you can have a WSDL and an endpoint request in the same tape rule.

Note:

Tape Rules will not work with SOAP messages that use credentials or headers with expiry dates in them.

11.3.13 How to Set Rules

Set rules to determine HTTP Analyzer functioning such as redirecting requests to a different host or URL, or emulating a web service. Use the procedure to set rules for an HTTP Analyzer instance.

You can set rules so that the HTTP Analyzer runs using behavior determined by those rules. Each analyzer instance can have a set of rules to determine behavior, for example, to redirect requests to a different host/URL, or to emulate a web service.

To set rules for an HTTP Analyzer instance:

Open the HTTP Analyzer by choosing Tools > HTTP Analyzer. The HTTP Analyzer docked window opens.

Alternatively, the HTT Analyzer automatically opens when you choose Test Web Service from the context menu of a web service container in the Applications window.
Click the Analyzer Preferences button to open the HTTP Analyzer preferences dialog, in which you can specify a new listener port, or change the default proxy.

Alternatively, choose Tools > Preferences, and then navigate to the HTTP Analyzer page.
Click Configure Rules to open the Rule Settings dialog in which you define rules to determine the actions the HTTP Analyzer should take. For more help at any time, press F1 or click Help in the Rule Settings dialog.
In the Rule Settings dialog, enter the URL of the reference service you want to test against as the Reference URL. This will help you when you start creating rules, as you will be able to see if and how the rule will be applied.
Define one or more rules for the service to run the client against. To add a new rule, click the down arrow next to Add, and choose the type of rule from the list. The fields in the dialog depend on the type of rule that is currently selected.
The rules are applied in order from top to bottom. Reorder them using the up and down reorder buttons. It is important that the last rule is a blank Pass Through rule.

11.3.14 Using the HTTP Analyzer with Web Services

Use the HTTP Analyzer to examine the content of web services.

This section contains information about using the HTTP Analyzer with web services developed in JDeveloper. In general, you can use HTTP Analyzer to examine the content of web services in the same way as using it to examine any packets across HTTP.

Note:

You cannot use the HTTP Analyzer to test JAX-RPC web services that have WebLogic Server 9.x policies attached. WebLogic 9.x policies have been deprecated in JAX-RPC.

11.3.14.1 Testing Web Services with the HTTP Analyzer

Test web services using the HTTP Analyzer to examine the network traffic of a proxy that is connected to a web service and was developed in JDeveloper. Use the procedure to test a web service.

JDeveloper allows you to test web services using the HTTP Analyzer to examine the network traffic of a proxy connecting to a web service developed in JDeveloper.

To test a web service:

Run the web service on the integrated application server and open the HTTP Analyzer by right-clicking the web service node in the Applications window, and choosing Test Web Service. JDeveloper automatically:
- Starts the integrated application server, if it is not already running.
- Compiles and binds the web service application to the integrated application server, which you can see in the Application Servers window.
- Displays a Log window for the integrated application server (if there is not one already open).
Enter a parameter to test the service in the Request pane of the HTTP Analyzer Test window and click Send Request.

The response from the deployed web service is displayed in the Response pane of the HTTP Analyzer Test window.

You can examine the contents of the HTTP headers of the request and response packets to see the SOAP structure, the HTTP content, the Hex content or the raw message contents by choosing the appropriate tab at the bottom of the HTTP Analyzer Test window.

11.3.14.2 Using the HTTP Analyzer with RESTful Web Services

The HTTP Analyzer reads a WADL created by Jersey for the RESTful web service, and the WADL is displayed in the HTTP Analyzer Test window. Use the procedure to examine the RESTful service, to test the RESTful service, and to work with the resource.

You can use the HTTP Analyzer to interact with RESTful web services. Representational State Transfer (REST) describes any simple interface that transmits data over a standardized interface (such as HTTP) without an additional messaging layer, such as SOAP. REST provides a set of design rules for creating stateless services that are viewed as resources, or sources of specific information, and can be identified by their unique URIs. A client accesses the resource using the URI, a standardized fixed set of methods, and a representation of the resource is returned. The client is said to transfer state with each new resource representation.

When using the HTTP protocol to access RESTful resources, the resource identifier is the URL of the resource and the standard operation to be performed on that resource is one of the HTTP methods: GET, PUT, DELETE, POST, or HEAD.

The HTTP Analyzer has support for Hypermedia as the Engine of Application State (HATEOAS), and so you can examine and test RESTful web services using the HTTP Analyzer.

Jersey and WADL

Java API for RESTful Web Services (JAX-RS) provides support for creating Web services according to the REST architectural style. JAX-RS uses annotations to simplify the development of RESTful Web services. By adding annotations to your Web service, you can define the resources and the actions that can be performed on those resources. WebLogic Server supports Jersey 2.x (JAX-RS 2.0 RI). Information about Jersey 2.x is available at: https://jersey.java.net/download.html.

JAX-RS 2.0 API Specification (Rev a) is available at: https://jax-rs-spec.java.net/nonav/2.0-rev-a/apidocs/index.html.

A Web Application Description Language (WADL) is an XML file created by Jersey that provides a description of the resources in the servlet. See https://wadl.dev.java.net/.

Testing a RESTful Service

An outline of testing a RESTful service using WADL is given here, with more detailed steps in the procedure below. Not all RESTful services work this way. The HTTP Analyzer reads a WADL created by Jersey for the RESTful web service, and you examine the WADL in the HTTP Analyzer Test window. From the WADL, you can open an instance of the HTTP Analyzer Test window directly from a method, and test the method by entering a parameter and posting it to the service. The HTTP Analyzer redirects the response to a new URL which it displays, and when you click on it another instance of the HTTP Analyzer Test window opens with the response. Once you have finished, you use the WADL to locate the new resource that the HTTP Analyzer created to test the service and delete it.

The following example provides an example of a WADL document which uses POST, GET and DELETE.

  <?xml version = '1.0' encoding = 'UTF-8' standalone = 'yes'?>
  <application xmlns="http://research.sun.com/wadl/2006/10">
     <doc xmlns:jersey="http://jersey.dev.java.net/"  jersey:generatedBy="Jersey: 1.1.0-ea 04/30/2009 04:46 PM"/>
     <resources  base="http://localhost:7101/RESTDemo-ContainerProject-context-root/jersey/">
        <resource path="buckets">
           <method name="POST" id="createNewBucket">
              <request>
                 <representation mediaType="*/*"/>
              </request>
              <response>
                 <representation mediaType="*/*"/>
              </response>
           </method>
           <method name="GET" id="getBuckets">
              <response>
                 <representation  mediaType="application/buckets+xml"/>
              </response>
           </method>
           <resource path="/{id}">
              <param xmlns:xs="http://www.w3.org/2001/XMLSchema"  type="xs:int" style="template" name="id"/>
              <method name="DELETE" id="delete">
                 <response>
                    <representation mediaType="*/*"/>
                 </response>
              </method>
              <method name="GET" id="getBucket">
                 <response>
                    <representation mediaType="*/*"/>
                 </response>
              </method>
           </resource>
        </resource>
     </resources>
  </application>

To test a REST web service

Testing a REST web service requires that you:

examine the RESTful service
test the service
work with the resource

To examine the RESTful service:

Run the REST web service on the integrated application server.
Right-click the web service node in the Applications window, and choose Test Web Service. JDeveloper automatically:
- Starts the integrated application server, if it is not already running.
- Compiles and binds the web service application to the integrated application server instance, which is the Integrated WebLogic Server node in the Application Servers window.
- Displays a Log window for the integrated application server (if there is not one already open).
Click the HTTP Content tab in the HTTP Analyzer Test window. RESTful web services do not use SOAP, so you will not use the SOAP Structure tab.
In the Log window for the integrated application server, click the link next to Target Application WADL. A second instance of the test window opens. Notice that the URL displays the WADL, and the Method is GET.
Click Send Request. The GET method is used to return the content of the WADL so that it is displayed in the Response pane.

If necessary, use the left arrow to maximize the width of the pane to see the code more clearly.
To view the WADL file at anytime, click Open WADL to the right of the RESTful web service URL. A read-only version of the WADL file opens in the source editor, enabling you to view the a summary of the RESTful web service resources and methods, or the WADL source. .

To test the RESTful service:

In the WADL displayed in the Response pane, press Ctrl+mouse-click to use the Go to declaration feature to reveal parts of the HTTP message that can be accessed. Click on a POST method that is now revealed as a link. This opens a new instance of the test window.
Enter a parameter in the Request pane, and click Send Request. The POST method is used, and the Request pane displays a 201 Created HTTP status code along with the location of the URL that contains the response.
Click on the URL in the Response pane. Another instance of the test window opens. Notice that the URL displays the redirected URL, and the Method is GET. Click Send Request, and the response to the parameter you entered is displayed in the Request pane.

Note:

When you click on the WADL, the correct content-type and accept headers will be generated.

To work with the resource:

Select the test window instance for the WADL, and navigate to the GET method. Press Ctrl+mouse-click to open a new instance of the test window. Notice that the URL displays the redirected URL, and the Method is GET.
You can update the resource by choosing PUT from the Method list, and click Send Request.
In order to delete this resource, choose DELETE from the Method list, and click Send Request.

11.3.15 Using the HTTP Analyzer with WebSockets

The HTTP Analyzer passes unsecured WebSockets requests by means of a proxy. The HTTP Analyzer displays the content of the request response stream.

The HTTP Analyzer will pass unsecured WebSockets requests via a proxy.

The content of the request response stream will be available in the HTTP Analyzer after you close and reopen the message. The WebSockets messages are those with a response code of 101.

11.3.16 Using the HTTP Analyze with Fast Infoset

If you want the HTTP Analyzer to work with the Fast Info set, override the Content-Type in the HTTP headers, so that it does not lapse into working with the default soap/xml.

The HTTP Analyzer works with Fast Info set, but it will default to sending soap/xml instead unless you override the Content-Type in the HTTP headers.

SOAP 1.1 Change the Content-Type to application/fastinfoset.

SOAP 1.2 Include the action name, for example

application/soap+fastinfoset;action=&quot;http://project1/HelloWorldSOAP12/helloRequest

11.3.17 Reference: Troubleshooting the HTTP Analyzer

This section contains information to help resolve problems that you may have when running the HTTP Analyzer.

11.3.17.1 Running the HTTP Analyzer While Another Application is Running

Stop any application that is waiting for a response before you start or stop the HTTP Analyzer.

If you have an application waiting for a response, do not start or stop the HTTP Analyzer. Terminate the application before starting or stopping the HTTP Analyzer.

11.3.17.2 Changing Proxy Settings

Change the proxy settings in JDeveloper when you use the HTTP Analyzer. Use the procedure to set the HTTP proxy server, and edit the exception list.

When you use the HTTP Analyzer, you may need to change the proxy settings in JDeveloper. For example:

If you are testing an external service and your machine is behind a firewall, ensure that the JDeveloper is using the HTTP proxy server.
If you are testing a service in the integrated application server, for example when you choose Test Web Service from the context menu of a web service in the Applications window, ensure that JDeveloper is not using the HTTP proxy server.

If you run the HTTP Analyzer, and see the message

500 Server Error
The following error occurred: [code=CANT_CONNECT_LOOPBACK] Cannot connect due to potential loopback problems

you probably need to add localhost|127.0.0.1 to the proxy exclusion list.

To set the HTTP proxy server and edit the exception list:

Choose Tools > Preferences, and select Web Browser and Proxy.
Ensure that Use HTTP Proxy Server is selected or deselected as appropriate.
Add any appropriate values to the Exceptions list, using | as the separator.

In order for Java to use localhost as the proxy ~localhost must be in the Exceptions list, even if it is the only entry.