## Java subsystems |

On this tab of the profiling settings dialog, you can select how JProfiler should record J2EE-related Java subsystems.

| Record service calls JProfiler instruments several J2EE service layers on the fly and records semantic data as well as execution times for these service calls. The instrumentation is not implementation dependent and works for all drivers or service providers. The service calls are annotated into the call tree view and can be selected as hot spot types in the hot spot view. 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 `MessageConsumer`s are measured. For asynchronous messages, the `onMessage` methods of `MessageListener`s 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.

| J2EE awareness If Split call tree for each request URL is enabled, JProfiler will analyze the URLs that occur in calls to servlets and JSPs. For each URL, a new node is created in the call tree. URLs can also be selected as a hot spot type in the hot spot view. In that way, you can differentiate the performance issues of separate pages or requests. 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.