About Debugging a Java Service while its Class Runs in Designer

In Designer, the primary way to debug a Java service is to debug the Java class associated with the Java service that Designer maintains in a Service Development Project.

Note:
As a secondary method of debugging a Java service, you can debug a Java service that is running in Integration Server. This method requires setup on the Integration Server to change the way the server starts and that can affect the server’s performance. For more information, see About Debugging a Java Service while it Runs in Integration Server .

The functionality that Designer provides to debug a Java service by debugging its Java class is an extension of the Eclipse Java Development Tools (JDT) debugger. The JDT debugger acts on Java classes that are in the local workspace; it cannot debug the Java service in Integration Server. As a result, to debug a Java service, you use the JDT debugger to debug the service’s Java class that Designer maintains in a Service Development Project. Debugging the Java class might produce different results than when the Java service executes in Integration Server, depending on differences in JVM system properties, date/time, time zone information, locale, language settings, encodings, etc.

When debugging a Java service in this way, you can debug the primary method and shared code of the Java class that represents the Java service. To debug the Java class, you launch it in debug mode and use the JDT debugger to suspend/resume the execution of the Java class, inspect variables, and evaluate expressions.

The actions you take to use the debugger are:

Optionally set breakpoints to identify locations where you want the debugger to suspend execution when running the Java class in debug mode. For more information, see How to Suspend Execution of a Java Class while Debugging.

Generate a test harness, which is a Java class that you generate for the Java service you want to debug. The logic that Designer generates for the test harness sets up the inputs, invokes the Java class, and displays the outputs.

Optionally create a Java Application launch configuration to configure settings for debugging the Java class. For example, you might want to set JVM arguments to match the settings Integration Server uses so that your test more closely matches how the Java service would execute in Integration Server. For more information, see About Java Application Launch Configuration. If you do not create a launch configuration, Designer creates one on the fly and saves it locally in an unexposed location of your workspace.

Launch the test harness in debug mode. The test harness prompts for input values and then launches the Java class you want to debug in debug mode.

By default, the debugger executes the Java class using the JRE in the Service Development Project where the Java service resides. You can change the Service Development Project’s JRE by updating the project’s Java Build Path property. You can also specifically identify the JRE to use for debugging by identifying the JRE in the Java Application launch configuration.

If the Java class being debugged invokes a service, the invoked service runs in Integration Server. The debugger treats the statement to invoke a service like any executable line of code in the Java class; that is, you can Step Over it and see results from it. You cannot use the debugger to Step Into the invoked service.

If the debugger suspends execution of the service, Designer switches to the Debug perspective. The Debug view will show the test harness class and be positioned at the statement where the execution was suspended. You can use the other views in the Debug perspective to inspect the state of the Java service to this point. You can use the actions in the Debug view toolbar to resume the execution. For more information about suspending execution, see How to Suspend Execution of a Java Class while Debugging.