The following service types can be enabled separately:

• JDBC calls
  JProfiler analyzes statements, prepared statements, callable statements as well as batches of statements and measures calls into all JDBC methods of type execute, executeQuery, executeUpdate and executeBatch.

  The displayed data is always the executed SQL statement, without any parameter substitution.

• JMS calls
  Both synchronous and asynchronous messages are handled. For synchronous messages, the receive and receiveNoWait methods of MessageConsumers are measured. For asynchronous messages, the onMessage methods of MessageListeners or message driven EJBs are measured.

  The displayed data is by default the message destination as returned by message.getJMSDestination(). If you would like to differentiate messages based on the content of the message you can write a custom JMSResolver and register it with Controller.registerJMSResolver. Please see the API documentation for more information.

• JNDI calls
  All calls in javax.naming.Context and javax.naming.directory.DirContext that return data are measured.

  Based on whether a call is a name lookup or a search call, the displayed data will be prefixed with [NAME] or [SEARCH] and contains information about the name or search expression in the parameters.

Service calls are grouped by their display data, i.e. two equal select statements at the same call stack are held as one node in the internal data model. For each node, JProfiler keeps track of the invocation count and total execution times for each thread status. To avoid an overload of the system, there's a maximum number of recorded service calls per call stack. If the maximum number is exceeded, the oldest call is merged into an "[earlier calls]" node. By default, this maximum value is set to 20, if you require more detail you can increase the value in the text field as needed.

By default, only the URL without the query parameters is used for the above splitting process. In order to retain selected parameters in the call tree, you can enter them in the text field labeled retained request parameters. For example, if you want to split the call tree for each different value of the parameters "action" and "level", enter action,level into the text field. If you would like to customize the splitting process (for example, if the session id is incorporated into the URL) you can write a custom HTTPRequestResolver and register it with Controller.registerHTTPRequestResolver. Please see the API documentation for more information.

Request URLs that do not lead to an unfiltered method in the call tree are not displayed by default. If you would like to display all requests, please check the checkbox labeled Show request URLs that are outside the call tree.

JProfiler can detect the following J2EE component types:

 servlets
 JSPs
 EJBs

The corresponding methods have a separate icon in the call tree. For JSPs, the name of the JSP source file is displayed instead of the generated class and for EJBs the name of the interface is displayed instead of the generated stub or proxy classes. In the "method" and the "class" aggregation levels, the real class names are displayed in square brackets, too.

Based on this component information, JProfiler offers the J2EE components aggregation level in all views with an aggregation level selector. If you would like to disable J2EE component detection, you can deselect the checkbox labeled Detect J2EE components.