FusionDebug Rev 4.0.x

RELEASE NOTES – KNOWN ISSUES – ADDITIONAL LICENSE AGREEMENTS

INTERGRAL INFORMATION SOLUTIONS GMBH
Schickardstr 32 – D-71034 Boeblingen – Germany

The FusionDebug software is Copyright (C) 2006-2016 Intergral Information Solutions GmbH.
All rights reserved. The FusionDebug software product is commercial software and may not be redistributed except with the express written agreement of Intergral Information Solutions GmbH.
The software may only be used in accordance with the appropriate FusionDebug license agreement.

Status: 3-MAR-2016

RELEASE NOTES

FusionDebug Rev 4.0.0

• New Feature: Support for ColdFusion 2016
• New Feature: Support for ColdFusion Builder 2016
• New Feature: Support for Lucee 4.5 and Railo 4.2
• New Feature: Support for Eclipse 4.4 ( Luna ) and 4.5 ( Mars )
• New Feature: Support for Java 1.8

FusionDebug Rev 3.7.1

• An issue which would cause FusionDebug to claim other Debuggers’ (notably FlexBuilder) breakpoints has been fixed.
• An issue which could cause Eclipse and Eclipse-based IDEs running on JDK 1.6 to fail to connect to any debug target (often causing a NullPointerException), or being able to display the Debug Launch Configuration page for FusionDebug launches, has been fixed.

FusionDebug Rev 3.7.0

• New Feature: Support for ColdFusion Builder 3
• New Feature: Support for ColdFusion 11

FusionDebug Rev. 3.6.1

• An issue whereby the Source Code Lookup tab’s dropdown list could not be changed has been fixed.

FusionDebug Rev. 3.6.0

• Support for Windows 8

• New Feature: Support for ColdFusion 10 and Railo 4
• New Feature: Support for Eclipse 4.3 (Kepler) and 4.2 (Juno)
• New Feature: Browse button on “Source Code Lookup” tab

• FusionDebug Rev. 3.6.0 has been tested using Eclipse Platform 4.1 to 4.3. FusionDebug is a pure Java application with no native dependencies, and so should run on all OS platforms for which Eclipse is available.

• We recommend installing the Eclipse Java SDK package. This can be obtained from http://www.eclipse.org/downloads/

• We recommend also installing the CFEclipse package, which provides a capable environment for working with CF scripts within Eclipse. This can be obtained from: http://www.cfeclipse.org/

• Please consult the relevant Guides for quick-start instructions on getting acquainted with FusionDebug. There is an updated User Manual for 3.6.0.

KNOWN ISSUES

The following issues are known at the time of publication.

General

• ‘Run To Line’ Causes Skip On Following CFML Code/Breakpoints With Resume/Steps

As Run To Line targets are set anywhere on a CFML page, and we expect the execution to halt at this point, the engine must be allowed to continue to the ‘next nearest’ valid CFML, and halt there. This can therefore be on another Breakpoint, causing it to seem (upon step/resume) to be skipped, where as it has simply already been hit.

• Custom Extensions Not Recognized By CFML Server

For your Custom Extensions to function you must add them to your CFML Servers known extensions. For advice on how to do this please see our user manual or web page. These contain useful links and setup instructions, as well as guides on setting your default editors. You will need to set your IDE to use editors that allow debugging on your new extensions (including the default .htm .html).

For information and instructions on use please see:
https://www.fusion-debug.com/support/

CF Specific

• Custom Exceptions Fire In CF Admin/Other CF Web Applications Pages When FusionDebug Connected

This is a side effect of breaking on Exceptions, any CFML Live code running on the attached server can fire off Custom Exceptions, which FusionDebug will detect (when option selected). To use these applications during a debug session simply uncheck the option to ‘Catch Un/Caught Custom CFML Exceptions’ in the FusionDebug ‘Configuration’ Page in ‘Preferences’, from the ‘Window’ menu option. You can then re-enable the setting once you have finished using the desired page and continue debugging.

• Custom Exceptions Within CFTRY Recognized As Caught When NOT Handled In CFCATCH

When placed within a cftry/cfcatch block thrown Custom Exceptions are dealt with as Caught by CFML. Therefore even though this is Uncaught by rights, it will only be detected as caught (with this option). When this occurs the catch block will be highlighted also – due to the match not being correct. The distinction between whether ‘this’ Custom Exception, is Caught based upon the catch type is something we are working on and plan to have resolved for next Beta/Release.

GENERAL ISSUES

Some Numerical / Complex CF Types Decode to Java Types, Not CF Types

We’re working hard on being able to decode all CFML complex types. Most types are already
implemented – structs, arrays, XML objects, CFCs, Functions etc. In some cases, you might see
an undecoded type in the Variables and Expressions view (“… instance of …”) or a plain
string representation of the object.

Step Over sometimes requires > 1 keypress to advance the cursor.

This is because some lines of CF code perform multiple actions and require you to press
step for each action that they perform.

Step Into CFC’s is sometimes requires > 1 keypress to step into the CFC.

With the current instruction pointer located on the CFINVOKE tag, keep clicking Step Into until
the CFC is loaded. The parameters and other initialization actions are performed before the CFC
is called. You may have to push step into until this initialization is complete.

Step Requests sometimes jump around to lines of code that are not sensible.

This is a limitation of how Railo processes and optimizes pages at compile time.

Calling CFML functions which are reentrant to the currently halted thread may cause the VM to hang

You cannot set/clear breakpoints with CTRL-SHIFT-B when in the CFEclipse perspective

CFEclipse does not support the CTRL-SHIFT-B keystroke when in the CFEclipse perspective. You
can toggle the breakpoint by right mouse clicking on the line you wish to set the breakpoint
on and using the Toggle Line Breakpoint menu item.

Sometimes breakpoints don’t fire.

In the Debug configuration, make sure the Target System Type is set correctly: checked for
Windows, unchecked for Unix. And the correct connector is being used for the engine type desired.

Breakpoints set on blank lines may not always fire.

Since FD 2.0.1 breakpoints can be set on blank lines. FD cannot always get breakpoints to
fire on blank lines because they are sometimes optimized away by the CF compiler.

Wrong File Selected

When a breakpoint or step event fires, FusionDebug does its best to find the source file. If the
same file exists multiple times in different projects, the wrong one may be selected
Use the source code lookup tab on the Launch Control to correct the source code lookups.

If your system is monitored by FusionReactor with crash protection activated, FusionReactor may

terminate the page if it exceeds the Request Timeout limit that has been configured. Please
deactivate crash protection in FusionReactor.

RESOLVED ISSUES

FusionDebug 3.6.1

FusionDebug 3.6.0

ADDITIONAL LICENSE AGREEMENTS

This Software contains code derived from the Eclipse Foundation (“Eclipse Code”).
Such Eclipse Source Code is made available under the terms of the Eclipse Public License v1.0 which
accompanies such code, and is also available at http://www.eclipse.org/legal/epl-v10.html

Eclipse Code. On behalf of Contributors to such Eclipse Code, Intergral hereby: (1) disclaims any and all
warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability
and fitness for a particular purpose with respect to such Eclipse Code and any and all derivative works thereof,
(2) disclaims any liability for damages, including direct, indirect, special, incidental and consequential
damages, such as lost profits, and (3) represents that any provisions in this License Agreement that differ
from the Eclipse Public License under which Intergral licensed the Eclipse Code, are offered by Intergral
alone and not by any other party. The source code for the Eclipse Code as contained in this Software may be
obtained by the Licensee as described in in this Readme to the Software. Intergral provides the Eclipse Code as
is, without warranty or support from Intergral.

By installing this product, in addition to the Intergral license terms, you also agree to be bound by the
third-party terms provided to you with the Intergral product documentation. Intergral recommends that you review
these third-party terms.

FusionDebug Rev. 3.7.x

RELEASE NOTES – KNOWN ISSUES – ADDITIONAL LICENSE AGREEMENTS

INTERGRAL INFORMATION SOLUTIONS GMBH
Schickardstr 32 – D-71034 Boeblingen – Germany

The FusionDebug software is Copyright (C) 2006-2015 Intergral Information Solutions GmbH.
All rights reserved. The FusionDebug software product is commercial software and may not be redistributed except with the express written agreement of Intergral Information Solutions GmbH.
The software may only be used in accordance with the appropriate FusionDebug license agreement.

Status: 25-MAR-2015

RELEASE NOTES

FusionDebug Rev 3.7.1

• An issue which would cause FusionDebug to claim other Debuggers’ (notably FlexBuilder) breakpoints has been fixed.
• An issue which could cause Eclipse and Eclipse-based IDEs running on JDK 1.6 to fail to connect to any debug target (often causing a NullPointerException), or being able to display the Debug Launch Configuration page for FusionDebug launches, has been fixed.

FusionDebug Rev 3.7.0

• New Feature: Support for ColdFusion Builder 3
• New Feature: Support for ColdFusion 11

FusionDebug Rev. 3.6.1

• An issue whereby the Source Code Lookup tab’s dropdown list could not be changed has been fixed.

FusionDebug Rev. 3.6.0

• Support for Windows 8

• New Feature: Support for ColdFusion 10 and Railo 4
• New Feature: Support for Eclipse 4.3 (Kepler) and 4.2 (Juno)
• New Feature: Browse button on “Source Code Lookup” tab

• FusionDebug Rev. 3.6.0 has been tested using Eclipse Platform 4.1 to 4.3. FusionDebug is a pure Java application with no native dependencies, and so should run on all OS platforms for which Eclipse is available.

• We recommend installing the Eclipse Java SDK package. This can be obtained from http://www.eclipse.org/downloads/

• We recommend also installing the CFEclipse package, which provides a capable environment for working with CF scripts within Eclipse. This can be obtained from: http://www.cfeclipse.org/

• Please consult the relevant Guides for quick-start instructions on getting acquainted with FusionDebug. There is an updated User Manual for 3.6.0.

KNOWN ISSUES

FusionDebug Rev. 3.6.x

The following issues are known at the time of publication.

General

• ‘Run To Line’ Causes Skip On Following CFML Code/Breakpoints With Resume/Steps

As Run To Line targets are set anywhere on a CFML page, and we expect the execution to halt at this point, the engine must be allowed to continue to the ‘next nearest’ valid CFML, and halt there. This can therefore be on another Breakpoint, causing it to seem (upon step/resume) to be skipped, where as it has simply already been hit.

• Custom Extensions Not Recognized By CFML Server

For your Custom Extensions to function you must add them to your CFML Servers known extensions. For advice on how to do this please see our user manual or web page. These contain useful links and setup instructions, as well as guides on setting your default editors. You will need to set your IDE to use editors that allow debugging on your new extensions (including the default .htm .html).

For information and instructions on use please see:
https://www.fusion-debug.com/fd/support.cfm

CF Specific

• Custom Exceptions Fire In CF Admin/Other CF Web Applications Pages When FusionDebug Connected

This is a side effect of breaking on Exceptions, any CFML Live code running on the attached server can fire off Custom Exceptions, which FusionDebug will detect (when option selected). To use these applications during a debug session simply uncheck the option to ‘Catch Un/Caught Custom CFML Exceptions’ in the FusionDebug ‘Configuration’ Page in ‘Preferences’, from the ‘Window’ menu option. You can then re-enable the setting once you have finished using the desired page and continue debugging.

• Custom Exceptions Within CFTRY Recognized As Caught When NOT Handled In CFCATCH

When placed within a cftry/cfcatch block thrown Custom Exceptions are dealt with as Caught by CFML. Therefore even though this is Uncaught by rights, it will only be detected as caught (with this option). When this occurs the catch block will be highlighted also – due to the match not being correct. The distinction between whether ‘this’ Custom Exception, is Caught based upon the catch type is something we are working on and plan to have resolved for next Beta/Release.

GENERAL ISSUES

Some Numerical / Complex CF Types Decode to Java Types, Not CF Types

We’re working hard on being able to decode all CFML complex types. Most types are already
implemented – structs, arrays, XML objects, CFCs, Functions etc. In some cases, you might see
an undecoded type in the Variables and Expressions view (“… instance of …”) or a plain
string representation of the object.

Step Over sometimes requires > 1 keypress to advance the cursor.

This is because some lines of CF code perform multiple actions and require you to press
step for each action that they perform.

Step Into CFC’s is sometimes requires > 1 keypress to step into the CFC.

With the current instruction pointer located on the CFINVOKE tag, keep clicking Step Into until
the CFC is loaded. The parameters and other initialization actions are performed before the CFC
is called. You may have to push step into until this initialization is complete.

Step Requests sometimes jump around to lines of code that are not sensible.

This is a limitation of how Railo processes and optimizes pages at compile time.

Calling CFML functions which are reentrant to the currently halted thread may cause the VM to hang

You cannot set/clear breakpoints with CTRL-SHIFT-B when in the CFEclipse perspective

CFEclipse does not support the CTRL-SHIFT-B keystroke when in the CFEclipse perspective. You
can toggle the breakpoint by right mouse clicking on the line you wish to set the breakpoint
on and using the Toggle Line Breakpoint menu item.

Sometimes breakpoints don’t fire.

In the Debug configuration, make sure the Target System Type is set correctly: checked for
Windows, unchecked for Unix. And the correct connector is being used for the engine type desired.

Breakpoints set on blank lines may not always fire.

Since FD 2.0.1 breakpoints can be set on blank lines. FD cannot always get breakpoints to
fire on blank lines because they are sometimes optimized away by the CF compiler.

Wrong File Selected

When a breakpoint or step event fires, FusionDebug does its best to find the source file. If the
same file exists multiple times in different projects, the wrong one may be selected
Use the source code lookup tab on the Launch Control to correct the source code lookups.

If your system is monitored by FusionReactor with crash protection activated, FusionReactor may

terminate the page if it exceeds the Request Timeout limit that has been configured. Please
deactivate crash protection in FusionReactor.

RESOLVED ISSUES

FusionDebug 3.6.1

FusionDebug 3.6.0

ADDITIONAL LICENSE AGREEMENTS

This Software contains code derived from the Eclipse Foundation (“Eclipse Code”).
Such Eclipse Source Code is made available under the terms of the Eclipse Public License v1.0 which
accompanies such code, and is also available at http://www.eclipse.org/legal/epl-v10.html

Eclipse Code. On behalf of Contributors to such Eclipse Code, Intergral hereby: (1) disclaims any and all
warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability
and fitness for a particular purpose with respect to such Eclipse Code and any and all derivative works thereof,
(2) disclaims any liability for damages, including direct, indirect, special, incidental and consequential
damages, such as lost profits, and (3) represents that any provisions in this License Agreement that differ
from the Eclipse Public License under which Intergral licensed the Eclipse Code, are offered by Intergral
alone and not by any other party. The source code for the Eclipse Code as contained in this Software may be
obtained by the Licensee as described in in this Readme to the Software. Intergral provides the Eclipse Code as
is, without warranty or support from Intergral.

By installing this product, in addition to the Intergral license terms, you also agree to be bound by the
third-party terms provided to you with the Intergral product documentation. Intergral recommends that you review
these third-party terms.

In order for FusionDebug to be able to read what line of code it is currently looking, the JVM needs to be put into debug mode. This procedure adds the required debugging parameters to a standard ColdFusion (JRun) installation.

1. Stop all running ColdFusion services.
2. Locate the Java configuration file jvm.config. This can be found in the following location:
   
   
   

   Windows:	C:\coldfusion11\cfusion\bin
   Unix:	/opt/coldfusion11/cfusion/bin/

3. Make a copy of this file, and store the copy somewhere on your disk. In case of problems, you can restore the copy to this location.
4. Open this file in a text editor (e.g. Notepad).
5. Locate the line java.args. These are the settings used to start the Java Virtual Machine, in which ColdFusion runs.
6. Find this option:
   
   
   
   -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
   
   
   
7. if it exists it should be change to match the following or if it does not then you need to insert the following after the java.args=. All options must be on the same line. Be careful not to introduce any line breaks:
   
   
   
   -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000
   
   
   
8. All options must be on the same line. Be careful not to introduce any line breaks.
   
   The following line is an example of a complete java.args parameter line:
   
   
   

   java.args=-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000 -server -Xms256m -Xmx512m -XX:MaxPermSize=192m -XX:+UseParallelGC -Xbatch -Dcoldfusion.home={application.home} -Djava.security.egd=/dev/urandom -Djava.awt.headless=true -Duser.language=en -Dcoldfusion.rootDir={application.home} -Djava.security.policy={application.home}/lib/coldfusion.policy -Djava.security.auth.policy={application.home}/lib/neo_jaas.policy  -Dcoldfusion.classPath={application.home}/lib/updates,{application.home}/lib,{application.home}/lib/axis2,{application.home}/gateway/lib/,{application.home}/wwwroot/WEB-INF/cfform/jars,{application.home}/wwwroot/WEB-INF/flex/jars,{application.home}/lib/oosdk/lib,{application.home}/lib/oosdk/classes -Dcoldfusion.libPath={application.home}/lib -Dorg.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER=true -Dcoldfusion.jsafe.defaultalgo=FIPS186Random   
   

   
   

9. If you have other applications running on port 8000, change the port address to a free port. Make a note of the new port
10. Start all ColdFusion services.

For more information about installing and using FusionDebug, please refer to the User Guide.

Symptoms

You may see one of more of the following errors:

java.lang.IllegalArgumentException: Argument not valid

java.lang.NullPointerException

java.lang.UnsupportedClassVersionError: com/sun/tools/jdi/LinkedHashMap : Unsupported major.minor version 51.0

java.lang.NoClassDefFoundError: Could not initialize class com.intergral.fusiondebug.api.driver.ui.preferences.C

Background

Eclipse environments still running on older 1.6 JVM versions are not compatible with one of the libraries used in our software.

Resolution

• Stop Eclipse environment that contains FusionDebug
• Delete (or move to a completely different folder outside of your eclipse environment) \eclipse\plugins\com.intergral.fusionreactor.debug.core_3.6.1\lib\tools-1.6.0_18.jar
• Copy the attached file tools-1.6.0_18.jar to that location
• Start Eclipse

The errors should now have gone.

FusionDebug Rev. 3.5.0

RELEASE NOTES – KNOWN ISSUES – ADDITIONAL LICENSE AGREEMENTS

INTERGRAL INFORMATION SOLUTIONS GMBH
Schickardstr 32 – D-71034 Boeblingen – Germany

The FusionDebug software is Copyright (C) 2006-2010 Intergral Information Solutions GmbH.
All rights reserved. The FusionDebug software product is commercial software and may not be
redistributed except with the express written agreement of Intergral Information Solutions GmbH.
The software may only be used in accordance with the appropriate FusionDebug license agreement.

Status: Tue, 9 Nov 2010

RELEASE NOTES

• FusionDebug Rev. 3.5.0

• Support for Windows 7

• New Feature: Breakpoints IP address restriction – Only fire breakpoints from a given IP address list
• New Feature: Auto detect the server debug platform type Window/Unix
• New Feature: Change Value on the Expression Menu

• FusionDebug Rev. 3.5.0 has been tested using Eclipse Platform 3.2 to 3.6 (Helios). FusionDebug is a pure Java
  application with no native dependencies, and so should run on all OS platforms for which Eclipse is
  available.

• We recommend installing the Eclipse Java SDK package. This can be obtained from http://www.eclipse.org/downloads/

• We recommend also installing the CFEclipse package, which provides a capable environment for
  working with CF scripts within Eclipse. This can be obtained from: http://www.cfeclipse.org/

• Please consult the relevant Guides for quick-start instructions on getting acquainted with FusionDebug. There is
  an updated User Manual for 3.5.0.

KNOWN ISSUES

FusionDebug Rev. 3.5.0

The following issues are known at the time of publication.

General

• ‘Run To Line’ Causes Skip On Following CFML Code/Breakpoints With Resume/Steps

As Run To Line targets are set anywhere on a CFML page, and we expect the execution to halt at this point, the engine must be allowed to continue to the ‘next nearest’ valid CFML, and halt there. This can therefore be on another Breakpoint, causing it to seem (upon step/resume) to be skipped, where as it has simply already been hit.

• Custom Extensions Not Recognized By CFML Server

For your Custom Extensions to function you must add them to your CFML Servers known extensions. For advice on how to do this please see our user manual or web page. These contain useful links and setup instructions, as well as guides on setting your default editors. You will need to set your IDE to use editors that allow debugging on your new extensions (including the default .htm .html).

For information and instructions on use please see:
https://www.fusion-debug.com/fd/support.cfm

CF Specific

• Custom Exceptions Fire In CF Admin/Other CF Web Applications Pages When FusionDebug Connected

This is a side effect of breaking on Exceptions, any CFML Live code running on the attached server can fire off Custom Exceptions, which FusionDebug will detect (when option selected). To use these applications during a debug session simply uncheck the option to ‘Catch Un/Caught Custom CFML Exceptions’ in the FusionDebug ‘Configuration’ Page in ‘Preferences’, from the ‘Window’ menu option. You can then re-enable the setting once you have finished using the desired page and continue debugging.

• Custom Exceptions Within CFTRY Recognized As Caught When NOT Handled In CFCATCH

When placed within a cftry/cfcatch block thrown Custom Exceptions are dealt with as Caught by CFML. Therefore even though this is Uncaught by rights, it will only be detected as caught (with this option). When this occurs the catch block will be highlighted also – due to the match not being correct. The distinction between whether ‘this’ Custom Exception, is Caught based upon the catch type is something we are working on and plan to have resolved for next Beta/Release.

GENERAL ISSUES

Some Numerical / Complex CF Types Decode to Java Types, Not CF Types

We’re working hard on being able to decode all CFML complex types. Most types are already
implemented – structs, arrays, XML objects, CFCs, Functions etc. In some cases, you might see
an undecoded type in the Variables and Expressions view (“… instance of …”) or a plain
string representation of the object.

Step Over sometimes requires > 1 keypress to advance the cursor.

This is because some lines of CF code perform multiple actions and require you to press
step for each action that they perform.

Step Into CFC’s is sometimes requires > 1 keypress to step into the CFC.

With the current instruction pointer located on the CFINVOKE tag, keep clicking Step Into until
the CFC is loaded. The parameters and other initialization actions are performed before the CFC
is called. You may have to push step into until this initialization is complete.

Step Requests sometimes jump around to lines of code that are not sensible.

This is a limitation of how Railo processes and optimizes pages at compile time.

Calling CFML functions which are reentrant to the currently halted thread may cause the VM to hang

You cannot set/clear breakpoints with CTRL-SHIFT-B when in the CFEclipse perspective

CFEclipse does not support the CTRL-SHIFT-B keystroke when in the CFEclipse perspective. You
can toggle the breakpoint by right mouse clicking on the line you wish to set the breakpoint
on and using the Toggle Line Breakpoint menu item.

Sometimes breakpoints don’t fire.

In the Debug configuration, make sure the Target System Type is set correctly: checked for
Windows, unchecked for Unix. And the correct connector is being used for the engine type desired.

Breakpoints set on blank lines may not always fire.

Since FD 2.0.1 breakpoints can be set on blank lines. FD cannot always get breakpoints to
fire on blank lines because they are sometimes optimized away by the CF compiler.

Wrong File Selected

When a breakpoint or step event fires, FusionDebug does its best to find the source file. If the
same file exists multiple times in different projects, the wrong one may be selected
Use the source code lookup tab on the Launch Control to correct the source code lookups.

If your system is monitored by FusionReactor with crash protection activated, FusionReactor may

terminate the page if it exceeds the Request Timeout limit that has been configured. Please
deactivate crash protection in FusionReactor.

RESOLVED ISSUES

ADDITIONAL LICENSE AGREEMENTS

This Software contains code derived from the Eclipse Foundation (“Eclipse Code”).
Such Eclipse Source Code is made available under the terms of the Eclipse Public License v1.0 which
accompanies such code, and is also available at http://www.eclipse.org/legal/epl-v10.html

Eclipse Code. On behalf of Contributors to such Eclipse Code, Intergral hereby: (1) disclaims any and all
warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability
and fitness for a particular purpose with respect to such Eclipse Code and any and all derivative works thereof,
(2) disclaims any liability for damages, including direct, indirect, special, incidental and consequential
damages, such as lost profits, and (3) represents that any provisions in this License Agreement that differ
from the Eclipse Public License under which Intergral licensed the Eclipse Code, are offered by Intergral
alone and not by any other party. The source code for the Eclipse Code as contained in this Software may be
obtained by the Licensee as described in in this Readme to the Software. Intergral provides the Eclipse Code as
is, without warranty or support from Intergral.

By installing this product, in addition to the Intergral license terms, you also agree to be bound by the
third-party terms provided to you with the Intergral product documentation. Intergral recommends that you review
these third-party terms.

Symptom

When trying to debug against a 1.7 JVM you receive a handshake error such as:

• Debugger failed to attach: recv failed during handshake: Resource temporarily unavailable
• com.intergral.fusiondebug.client.model.FDModelConnectionException: java.net.SocketException: Software caused connection abort: socket write error
• com.intergral.fusiondebug.client.model.FDModelConnectionException: java.io.IOException: Target failed to handshake

Background

Oracle/Sun changed the JVM debug connection handshake in the 1.7 JVM series; somewhere after update 2.

Fix

Note: This fix applies only to FusionDebug 3.5.0 users.

1. Stop Eclipse
2. Backup and remove the tools-1.4.2_10.jar from the com.intergral.fusionreactor.debug.core_3.5.0/lib folder
   • <eclipseinstallfolder>/plugins/com.intergral.fusionreactor.debug.core_3.5.0/lib
3. Copy the attached tools-1.4.2_10.jar file to the com.intergral.fusionreactor.debug.core_3.5.0/lib folder.
4. Start Eclipse

Debugging Flash Remoting and Gateway Messaging

Non-Intrusive debugging has been introduced in FusionDebug 3.5, which allows breakpoints to only fire when requests are coming from a specified IP address. This makes it possible for a developer to debug and set breakpoints against a central server, leaving the system untouched and unaffected for everyone else.

This article will demonstrate that the breakpoint IP filter can be used to debug Flash Remoting and Gateway Messages. In order to demonstrate that FusionDebug’s non-Intrusive debugging functionality is effective across a wide range of message types, below is a short example of testing the filter functionality in regards to Flash Remoting messages and Gateway messaging. I have based these tests on the test classes found at http://www.cftips.net and http://www.fusioncube.net .

Flash Remoting

I created a Flex project with an mxml file containing a script that has two functions; a function that simply populates a data grid with the results returned by a remote CFC and a second function that accepts a fault event and displays an error message in case of problems. I also need a remote object call specifying a destination named ColdFusion (which is configured with the appropriate channel for the passing of messages) and specified the location of the CFC you would like to access as well as creating a data grid to store the retreived results.

<mx:Script>
      <![CDATA[
            import mx.controls.Alert;
            import mx.rpc.events.FaultEvent;
            import mx.rpc.Fault;
            import mx.rpc.events.ResultEvent;
            
            private function result(evt:ResultEvent):void {
            	mygrid.dataProvider = evt.result;
           }

            private function fault(evt:FaultEvent):void {
                  Alert.show(evt.fault.message);                 
            }
      ]]>
</mx:Script>

<mx:RemoteObject id="mycfc" destination="ColdFusion" showBusyCursor="true" source="flashRemote" result="result(event)" fault="fault(event)">
</mx:RemoteObject>     
      <mx:Button label="Button" click="mycfc.GetData()"/>
      <mx:DataGrid id="mygrid" width="487" height="169"/>
</mx:Application>

Below are some changes that I found needed to be made to CF8 and CF9 Application servers’ configuration before the Flash Remoting test class would function correctly;
Within flex-messaging-gateway.cfg. If your Flex server is installed as part of your CF app server, comment out localhost ‘#host=localhost’. Specify ‘localhost’ if Flex is on this machine but not installed as part of ColdFusion.

For the Remoting-config.xml add the following code within the “ColdFusion” destination properties . You are setting use-mappings to true and setting the method-access-level to remote. use-mappings is a Boolean value specifying whether the source attribute can be relative to a ColdFusion mapping. Changing the method access level to remote basically specifies the access attribute values the destination CFC must have for ColdFusion to respond to the request. The code within the property-case tags simply state to make query column names, and structure keys lowercase when converting to ActionScript.

<destination id="ColdFusion">
   <channels>
      <channel ref="my-cfamf"/>
   </channels>
   <properties>
      <source>*</source>
   <access>
      <use-mappings>true</use-mappings>
      <method-access-level>remote</method-access-level>
   </access>
.....

Next you will need to adjust the access rights within the CFC function definition. Placing in whatever access level has been defined within the Remoting-config.xml. Flex can can access functions that are both remote or public. This CFC server side can just be a simple database query, so long as the function returns data to populate the data grid. The CFC in this example performs a query on a table within a defined data source. If you wanted to do the same, simply create a table within MYSQL or MSSQL and set it as a data source within the ColdFusion administrator.

<cffunction name="GetData" access="remote" returntype="query">

Configuring FusionDebug

Start up Eclipse with the FusionDebug Plug-in installed. Create a new Debug Configuration (Run->Debug Configurations…) for FusionDebug and configure the debugging port for your app server. In the IP Restrictions enter the IP address(es) of the server(s) that you want breakpoints to fire for. This means that when the request originates from one of the IP addresses you’ve entered it, the breakpoint should fire but for other requests the breakpoint will be ignored.

You then will have to navigate to the Source Code Lookup tab. Here you will simply need to select the project you want to debug and reference it’s source in the directory. Add the lookup and you are ready to start debugging.

Start debugging by pressing the Debug button at the bottom of the debug configuration screen. Once the debugger is attached open the CFC and add some breakpoints where you want to stop execution of the code.

Now run your Flex application up and make a request from an IP address that is in the list of IP Restrictions. FusionDebug halts the activity for only the flash remoting requests whose IP addresses have been entered into the IP filter, so if you make a request for a different machine then the breakpoint doesn’t fire. If you are using an app server on your local machine, CF8 and CF9 use loopback addressing and as a result uses the Ipv6 address 0:0:0:0:0:0:0:1 for localhost if you are using Windows Vista or 7 operating systems.

Whereas request from clients that are not in the IP restrictions list run to completion without the breakpoints firing! That’s Non-Intrusive Debugging!

Messaging Gateways

Below is a short example of testing the non-Intrusive debugging functionality in regards to ColdFusion Gateway messages.

Create a Flex project with a main mxml that contains a script block with a function that creates a producer and consumer object along with event listeners and remote destinations.

import mx.messaging.Consumer;
import mx.messaging.Producer;

private var publisher:Producer;
private var subscriber:Consumer;

private function createChat():void
{
   publisher= new Producer(); 
   publisher.addEventListener(MessageFaultEvent.FAULT, producerFault);
   publisher.destination = "ColdFusionGateway";

   subscriber= new Consumer();
   subscriber.addEventListener(MessageAckEvent.ACKNOWLEDGE, acknowledge);
   subscriber.addEventListener(MessageEvent.MESSAGE, receiveMessage);
   subscriber.destination = "ColdFusionGateway";
   subscriber.subtopic = "test";
   subscriber.subscribe();
}

The you will need to write a function for the handling of the acknowledgement event from the consumer, functions for sending and receiving messages and a function for handling a fault event from the producer.

private function producerFault(faultEvent:MessageFaultEvent):void
{
   output.text += "[Error: " + faultEvent.message.toString() + "]\n";
}
private function acknowledge(ackEvent:MessageAckEvent):void
{
   output.text += "[Contact with the Consumer has been established.]\n";
}

private function sendChatMessage():void 
{
   var msg:AsyncMessage = new AsyncMessage();
   msg.body = input.text;
   msg.headers["uname"] = "tester";
   msg.headers["gatewayid"] = "flexgateway";
   publisher.subtopic = "test";
   publisher.send(msg);
   input.text = "";
}

private function receiveMessage(msgEvent:MessageEvent):void
{
   var msg:AsyncMessage = AsyncMessage(msgEvent.message);
   output.text += msg.headers["uname"] + ": " + msg.body + "\n";
}

Within the content root of your CF app server (a.k.a wwwroot folder) you should place the CFC that you are using to interact with. This will contain a function that will return a message to the caller via the same destination and channel.

<cfcomponent output="false">
   <cffunction name="onIncomingMessage" returntype="any">
         <cfargument name="event" type="struct" required="true" />	 
	  <cfscript>
		x = structNew();
	        x.body = "Hello Friend";
		x.destination = "ColdFusionGateway";
		x.headers = structNew();
		x.headers['uname'] = "system";
		x.headers['DSSubtopic'] = "test";
		x.lowercasekeys = "yes";
      </cfscript>
   <cfreturn x /> 
 </cffunction>
</cfcomponent>

Some changes that may need to be made to CF8 and CF9 Application servers’ configuration before Flash Gateway usage, the first being within the corssdomain.xml file, make sure the contents allows all domain policies, all domains and all ports. Obviously there would be security issues with the following changes, but since this is just an example of Flash Remoting we will allow all ports and domains, but in reality these should be appropriately restricted.

<cross-domain-policy>
   <site-control permitted-cross-domain-policies="all" />
   <allow-access-from domain="*" secure="false" to-ports="*"/>
   <allow-http-request-headers-from domain="localhost"/>
</cross-domain-policy>

Within the messaging-config.xml set the server properties as shown below within the destination “ColdFusionGateway” properties.

<destination id="ColdFusionGateway">
   <adapter ref="cfgateway" />
      <properties>		
         <server>
            <durable>false</durable>
            <allow-subtopics>true</allow-subtopics>
         </server>
.....

A subtopic is a property of both the producer and consumer components, within the xml you are configuring the destination “ColdFusionGateway” to allow the subtopic to be used as a message destination. Setting the server configuration durable to false allows for messaging without the JMS (Java Messaging Service) API. If you are running Flex server with ColdFusion comment out the “host=localhost” line within the flex-messaging-gateway config file. This is located within the root ColdFusion directory \gateway\config\, else if Flex is on this machine but not installed as part of ColdFusion specify localhost.

You can configure your app server gateways for CF8 and CF9 as shown below in order to create the appropriate gateway needed for this example:

CF8

CF9

The counter of your Gateway should be 0 before the test has been executed. After the test is run both the ‘in’ and ‘out’ counter should display one message each in their fields (The in-going message being the call for the CFC via the ColdFusion channel. The outgoing message being the response from the CFC I.E. the body of the cfscript) When the program is first launched you should see the confirmation of contact from the Consumer.

Once some message has been entered, you should then see the message coming from the CFC.

FusionDebug halts the process of the CFC for specific users listed within the IP Restriction configuration options. All IP’s not entered within the filtering box will simple run the app as normal.

Conclusion

The non-Intrusive debugging feature ultimately provides a development team with the ability to debug their code without affecting other team members. It could even be that you need to debug a request from a specific client because they are the only one that experiences a problem. Non-Intrusive debugging can be used here to filter the requests that fire the breakpoints to only the problem client. This results in saving time and allowing bugs to be spotted earlier on within the development stage of production and can also lead to decreasing time consumed by debugging newly implemented components.

Source Code: FD128source.zip

Non-Intrusive Debugging

Non-Intrusive debugging has been introduced in FusionDebug 3.5, which allows breakpoints to only fire when requests are coming from a specified IP address. This makes it possible for a developer to debug and set breakpoints against a central server, leaving the system untouched and unaffected for everyone else.

This article will cover how to configure and use Non-Intrusive Debugging, the underlying implementation and a few tips on what to do if your breakpoints don’t fire when they are supposed to. The last section will also talk about the limitations of the Non-Intrusive Debugging feature in FusionDebug.

Configuration

Non-Intrusive Debugging can be enabled on any new or existent Debug Configurations in FusionDebug 3.5. This is done by entering the IP addresses to break on in the IP Restriction section available in the Connect Tab of the Debug Configuration to edit.

The IP Restriction feature in FusionDebug supports both IPv4 and IPv6 addresses, but there is no input validation so make sure these are entered correctly using standard IPv4 and IPv6 formats.

So for example say you only want breakpoints to fire when connecting locally, then you can enter 127.0.0.1 if connecting using IPv4 and 0:0:0:0:0:0:0:1 if using IPv6.

Multiple IP addresses can be specified by using a comma (,) to separate them, so in the previous example we can make sure that the breakpoints fire when connecting locally using either IPv4 or IPv6 by specifying them both like this: 127.0.0.1, 0:0:0:0:0:0:0:1

An example of this can be seen in the image below.

After the Non-Intrusive Debugging settings have been entered, click Apply to save the setting to the configuration. Please note that the debug session will have to be re-launched for the new IP Restriction properties to take effect.

Under the hood

When a request is made to the server being debugged in FusionDebug the connected IP address is compared to the ones entered in the Debug Configuration of the launched session.

FusionDebug does this by evaluating the CGI.REMOTE_ADDR variable for the request with the ones specified in the Debug Configuration screen. If the cgi.remote_addr variable matches any of the ones entered the breakpoints will fire as usual, otherwise they will not.

It is important to understand that FusionDebug can only evaluate the value that the ColdFusion server has stored. For example if the connection to the server is going through a proxy, FusionDebug will compare the IP address of the proxy and not the end user’s.

Also the entered IP addresses must exactly match the value of the cgi.remote_addr variable, no wildcards are allowed. For example you cannot enter 192.168.1.*, you will have to specify all the exact IP addresses to break on.

Adobe ColdFusion and Railo servers might also deal with different connection types differently and the value of cgi.remote_addr might differ slightly from server to server.

It is important to know that if the cgi.remote_addr variable cannot be evaluated, i.e. it has not been set properly, Non-intrusive Debugging will not function.

My breakpoints don’t fire

If you have enabled Non-Intrusive Debugging but the breakpoints do not fire or behave in the way you are expecting them to do, here are a few trouble-shooting tips.

IP addresses correctly entered

Make sure that the IP addresses to break on are specified correctly in the Debug Configuration using standard IP address notation and that no extra commas or dots have been introduced. Also make sure that the debug configuration settings have been saved.

IPv4 and IPv6

Make sure that you have not entered an IPv4 address when in fact the IP address reaching the server is an IPv6. Please note that different computers and operating systems will send different addresses depending on the network configuration. For example Microsoft Windows 7 has IPv6 enabled by default.
Also be aware that various servers will support different IP versions.

For example localhost can be specified as both an IPv4 and IPv6 address:
IPv4: 127.0.0.1
IPv6: 0:0:0:0:0:0:0:1

To be sure that the breakpoints fire on either the IPv4 or the IPv6 address both can be specified in the IP Restriction configuration, as in the image above.

Re-launch the debug session

It is not enough to just apply the new Non-Intrusive Debugging settings for the active Debug Configuration, but the actual debug session in FusionDebug has to be re-launched. This is because the IP Restriction properties are applied to the debug session at launch and cannot later be edited.

Inspect CGI.REMOTE_ADDR

If Non-Intrusive Debugging has been set up correctly but breakpoints still do not fire when they are expected to, a good thing is to actually check what value the cgi.remote_addr variable has been given.

One way to this is to have a CFML page containing this example code:

<cfoutput>remote_addr: #cgi.remote_addr#</cfoutput>

This will output the value of the cgi.remote_addr variable so that you can compare it to the ones entered in the Debug Configuration.

Another way is to inspect the value of cgi.remote_addr using FusionDebug. To do this you will have to disable Non-Intrusive Debugging by removing all the IP addresses in the Addresses field in the IP Restriction section of the Debug Configuration screen.

Once this has been done, apply the settings and re-launch the debug session and set a breakpoint on a page. Request this page from the machine you wish to enable Non-Intrusive Debugging for and the breakpoint should fire as normal.

You can now inspect the value of CGI.REMOTE_ADDR by selecting the Variables view tab in FusionDebug.

For Adobe ColdFusion:
Select the APPLICATION, REQUEST, SESSION, SERVER, CGI… Variable scope.
In this scope select CGI and scroll down the list of variables and locate the variable called REMOTE_ADDR.

For Railo:
Select the cgi Variable scope and scroll down the list of variables and locate the variable called remote_addr.

You can now copy the value of this variable and paste it in the Addresses field in the IP Restriction section of the Debug Configuration screen.

Proxy servers

If there is a proxy server between the user making the request and the server running ColdFusion, the value of the cgi.remote_addr variable will be set with the IP address of the proxy server and not the actual end user’s. This can create problems if there are multiple machines behind a proxy server and you only wish to break on a specified local IP.

Clear existent breakpoints

If breakpoints still do not fire when they are supposed to or behave in an unexpected way, it is a good idea to go to the Breakpoints view tab and delete all of the existent breakpoints and re-add them.

Sometimes breakpoints from an older version of FusionDebug will not work properly in a newer version, also if there is one bad breakpoint it might cause issues for other enabled breakpoints.

Limitations

There are many ways a request can be made to a ColdFusion server, for example http, flash remoting, web services, messaging gateway and more. We have tested FusionDebug using several different requests types and there is a DevNet article available covering this in more detail, “Debugging Flash Remoting and Gateway Messaging”.

As the Non-Intrusive Debugging feature in FusionDebug uses the value of the cgi.remote_addr variable for the request there will be cases when this variable is not being set and can therefore not be evaluated.

If you have specified IP addresses to filter breakpoints on and cgi.remote_addr doesn’t actually contain a value the breakpoints will not fire as FusionDebug would not know where the request came from.

Quickstart Guide: FusionDebug for Railo

This document should get you up and running with FusionDebug for Railo 3.1 (or higher)

Minimum Software

In order to start debugging Railo, you will need to download the following external components:

• Eclipse – You should download the Eclipse IDE for Java Developers (this contains all the components required for FusionDebug). Eclipse is a software framework that isn’t just for Java – you can use it for ColdFusion too. The package can be found here.

• Railo – You should download a build of Railo Express, available here.

• FusionDebug for Railo – Install/Update Package for Eclipse – This is available here

• Replacement Railo Express start scripts – These scripts run Railo with Java Debugging enabled – required for FusionDebug to connect to Railo. There is a replacement start.bat for Windows, and a replacement start for Mac OS X. They are available here. The replacement scripts instruct Java to start listening for FusionDebug on port 8000. *If your port 8000 is already in use, you can change this value by editing the startup script, but don’t forget to change it later when you create a Railo launch).

Installation

Railo Express

Railo Express doesn’t have an installer and must simply be unpacked to wherever it is required. Once unpacked, locate the appropriate start.bat file (or start for Mac OS X) and replace it with ours.

For the examples coming a little later, we assume you have unpacked Railo into the folder:

• c:\ railo-3.1.0.012-railo-express-6.1.0-3-1-with-jre-windows

Check that Railo starts up using your script. You can leave it running for now.

Eclipse

Eclipse also doesn’t have an installer; simply unpack it into wherever you would like it to live.

When you start Eclipse for the first time, it will ask you to locate a Workspace. This is where new projects will be created by default, and where Eclipse will store some configuration information.

If you have existing projects, Eclipse can be set up to use them wherever they are – they don’t need to be in the Workspace.

Once you have selected a Workspace, Eclipse will start up into the Welcome perspective.

Install FusionDebug into Eclipse

• Inside Eclipse, click on Window -> Open Perspective -> Debug to activate the debugging tools.
• Click on Help -> Software Updates to open the Eclipse P2 Software Updates and Add-ons manager.
• Select Help -> Software Updates -> Find and Install. This will bring up the Install/Update dialog.
• Select “Search for new features in Install” and click Next.
• Select “New Remote Site”. You will see a new dialog
• Enter the following information:
  • Name: FusionDebug Update Site
  • URL: http://www.fusion-reactor.com/fd/fd3update/
• then click OK.
• In the Install/Update dialog, ensure the FusionDebug Update Site is checked, then click Finish.
• The update manager will connect to fusion-reactor.com and locate the plugin. Once found, a new dialog will appear. Place a check mark against the “FusionDebug Update Site” and click Next.
• After you have read and accepted the terms and license agreement, click Next.
• Finally, click Finish to complete the process. When the Feature Verification dialog appears, click Install All.
• Eclipse will ask if it should restart the Workbench. Answer Yes and the workbench will be restarted.

FusionDebug is now installed.

First Session with FusionDebug

Let’s create a useful Debug perspective within Eclipse.

• Eclipse should restart already in the Debug perspective. If not, click on Window -> Open Perspective -> Debug to activate the debugging tools.
• The Debug perspective can be customized to make it a bit more useful than it is right out of the box:
  • Close the Outline view by clicking the X icon on the tab.
  • Add the Project Explorer view to the perspective by clicking Window -> Show View -> Other…, then open General and select Project Explorer. Click OK.
  • Eclipse adds the Project Explorer tab to the lower set. This isn’t much use. Grab the Project Explorer tab and drag it to the left of the central empty space. Eclipse ghosts the region where it will appear. When the ghost rectangle is located where you would like the Project Explorer, release the mouse. The view should then re-open in the new location.

• Ensure FusionDebug is installed by clicking Window -> Preferences. You should see a FusionDebug preference item. Close the preferences window by clicking OK.

Now we should tell Eclipse where our project is. For simplicity, we’ll use the Railo web root as a project. Then any files we create will automatically be created within the Railo web root.

• Right click inside the Project Explorer and select New -> Project. In the New Project wizard, open General and select Project. For the Project Name, enter “Railo Webroot” and uncheck the Use default location checkbox. We don’t want to create a new project in the Workspace.
• Use the Browse button to navigate to the webroot folder within Railo Express. If you unpacked Railo as mentioned above, this will be:
  • C:\railo-3.1.0.012-railo-express-6.1.0-3-1-with-jre-windows\webroot
• Click Finish. You should see that Eclipse has found the existing webroot, and it contains only the default Railo index.cfm.

• Open the default index.cfm file by double-clicking it. If another application opens the file (perhaps because .cfm is associated with another application), you can open the file within Eclipse by either:
  • dragging it into the gray editor area, or
  • right-click the file and select Open With -> Text Editor
• Make sure you can run the index file in a browser. With Railo Express started, navigate to *http://localhost:8888/index.cfm* … you should see Railos colorful default dump page.

Now the file is open in Eclipse, we can try to debug it. We first need to set up a Debug Configuration. This is a FusionDebug configuration specific to the server you want to debug.

• On the Eclipse toolbar, you can see a small green bug icon with a black down-arrow. Click the arrow and select Debug Configurations.
• Right-click on the FusionDebug icon and select New
• Give the configuration a useful name: Railo 3.1.0 on Localhost (for instance).
• In the Connect tab, ensure the details are correct – in particular the port (if you changed it earlier in the start script) and the checkbox for the server type. Leave it checked for Windows, unchecked for Unix.
• We have to tell FusionDebug how to map pages that run on the server to the projects in our Project Explorer view. Click on the Source Code Lookup tab.
• Since we only have one project, we can use the default <All Projects> mapping. In the upper area, enter the path to the Railo webroot (in our example this was C:\railo-3.1.0.012-railo-express-6.1.0-3-1-with-jre-windows\webroot), and click Add. Now click Apply.
• With the Debug Configurations wizard still open, click Debug.

If all has gone well, you should see FusionDebug (localhost:8000) (Connected) in the Debug view.

Let’s put a breakpoint in the page. Execution will stop when it hits a breakpoint.

• Find the line (it’s line 21) that says <cfdump var=”#test#” label=”test”> and left click to put the cursor on it.
• Now right-click on that line and select Toggle Line Breakpoint.
• You should see a small blue circle appear in the gutter margin. If you select the Breakpoints tab, you should see an entry describing it too – along with where FusionDebug thinks the exact file is on the server.
• In a browser, run the index.cfm page again.

Execution halts on the breakpoint.

• If you switch back to Eclipse, you can see:
  • The Debug view shows a stopped thread (probably named btpool0-something), with the index.cfm page, the line number and the project file.
  • The Editor has highlighted the line.

Let’s look at the Variables view.

• Click the Variables tab to bring the view into focus. This view is showing all the active CFML scopes.
• You can see that the three lines above where we’re stopped set three variables in three different scopes.
• Open these scopes (variables, url and form).

You can inspect any expression without locating it in the Variables view first.

• In the editor, select the text url.test, then right-click and select Inspect Expression.
  • A small dialogue should open with the result of the expression: “Hallo URL”.
  • If you instead see (not visible), Railo couldn’t work out what you wanted to inspect – check you’ve selected the exact text url.test.

Stepping. You can now step the page in three ways. Stepping executes one instruction at a time.

• The step functions correspond to the three yellow arrows at the top of the Debug view.
  • The first is Step Into. If you were on a statement which called another CF page (e.g. CFC method invoke, or cfinclude), Step Into will take you into that page.
  • The second is Step Over. This will execute the instruction under the cursor and go to the next one, but it won’t descend into any CFCs, UDFs or CFIncluded pages.
  • The third is Step Return. If you found yourself within a UDF, CFC or CFIncluded page, this step would execute all the remaining script within the UDF/CFC etc., and return you to the calling page.
• Try it out by clicking Step Over (the middle arrow) a few times: you can see execution advance, line by line, while variables are updated in real time.

If you step all the way to the end of the page, you’ll see the page complete and it will disappear from the Debug view. If you don’t want to wait, click the green Resume arrow at the top of the debug view. Provided no further breakpoints are hit, the page should complete.

When you are ready to finish your debug session, right-click on the name of the configuration in the Debug view (“Railo 3.1.0 on Localhost”, if you used our example) and select Disconnect.