No. Simply call the page in the web browser as you normally would. The port configured in jvm.config is for the internal debugging data and is not related to the web server or web browser.

There are two places where users often experience issues when configuring FusionDebug 1.0.

The first is with the Webroot folder; this value must be the path to the folder on the actual CF server. e.g. the value should not be the name of a share Q:\CFusionMX7\wwwroot, it should actually be: C:\CFusionMX7\wwwroot where the files are placed on the server.

The second issue tends to be that FusionDebug may pick the wrong source file to display, if you map your project to the webroot folder and have mulitple files of the same name in different folders. However this is very simple to fix, and can be done so by turning on the Search for Duplicate Source Files checkbox on source code tab of the Fusion Debug Launch Control.

Breakpoints Don’t Fire: Setting Webserver Folder and Eclipse Project Structure

Problem:

• Breakpoints don’t fire at all
• Breakpoints don’t fire in CFM/CFC pages in subfolders

Two of the most important options in FusionDebug are Webserver Folder, and Eclipse folder structure mirrors webserver. This article discusses how to configure these options in detail.

FusionDebug uses the information in the Configuration Dialog (accessible from the Run -> Debug menu) to accurately set breakpoints. If the information in this dialog is not configured correctly, FusionDebug may report that a breakpoint has been set, but it never fires: the associated page always runs to completion.

Solution:

In most cases, this problem can be solved by correctly configuring the Webserver Folder and Eclipse folder structure options in FusionDebug. Once these options are correctly configured, the configuration usually doesn’t need to be subsequently changed.

FusionDebug needs to know exactly where on your ColdFusion server the files are located, and how folders are structured. It uses these options, together with your Eclipse folder structure, to accurately set breakpoints and select the correct files when breakpoints fire.

Please note that FusionDebug 2 has an enhanced source code lookup system.

This is a known bug of the FusionDebug Setups on Linux and Solaris platforms not saving meta data about the installation in the Java Preferences User Backing Store if the Java Preferences System Backing Store in directory /etc/.java/.systemPrefs does not exist or is write protected.

Workaround

If the Setup does not detect a previously installed version you can install on top of the existing version to update it.

Background information

FusionDebug Setup and FusionDebug itself make use of the Java Preferences API to read and write data about the installation and other parameters from and to the so called Java Preferences Backing Store on the destination computer.
On Windows the location of the Backing Store is in the Windows Registry, on MacOS, Linux and Solaris the location of the Backing Store is typically the file system. The Backing Store itself is made up of a System and a User part that reside in different locations.

Windows

On Windows the System Backing Store is located in the registry in [HKEY_LOCAL_MACHINE\Software\JavaSoft\Prefs] whereas the User Backing Store is located in [HKEY_CURRENT_USER\Software\JavaSoft\Prefs].

MacOS

On MacOS the System Backing Store is a set of *.plist files in the directory /Library/Preferences, the User Backing Store is a set of *.plist files in the directory $HOME/Library/Preferences.

Linux and Solaris

On Linux and Solaris the System and the User Backing Store are a hierarchy of XML files. There can be multiple locations for the System Backing Store. If the directory /etc/.java/.systemPrefs exists and is writable it will be used as the System Backing Store, otherwise the directory $JAVA_HOME/jre/.systemPrefs will be tested. If this directory is writable or can be created it will be used as the System Backing Store. If this does not work no System Backing Store will be available.
The User Backing Store is located in the directory $HOME/.java/.userPrefs.

Depending on the privileges of the user that runs the Setup, data about the installation is stored in one of the two possible places described above. FusionDebug Setup first tries to access the System Backing Store and uses the User Backing Store if it cannot write to the System Backing Store. Due to a bug in a third party API which is used by the FusionDebug Setup this does not work correctly on Linux and Solaris.

There are three possible causes here:

• Ensure that FusionDebug has actually completed the step. If the Debug View still shows the CF page is “(Stepping)”, wait until this completes. Sometimes this can take a few seconds, depending on whether the page has been run previously.

• ColdFusion may have optimized the CFC constructor call away, or placed it on a line other than the original source code line. Try performing “Step Into” from the line prior to the tag which constructs the CFC.

Another thing that can make stepping seem not to work exhibits itself while control is stopped on a given breakpoint. Despite subsequent requests to step through code, no new lines seem to be reached in the file editor, but if you watch the stack trace pane you see the line numbers properly stepping through the code. The problem occurs because you have opened the file using the file system rather than an Eclipse “project”. FusionDebug only works with Eclipse projects, please open the file by clicking on it from within the Eclipse project instead of using the Eclipse File->Open File… menu.

This can occur if you haved used Eclipse’s Software Updates -> Manage Configuration dialog to revert your FusionDebug installation from 2.0.0 to 1.0.0. The original FD2 Trial license (serial number FD200TST) is still installed.

Additionaly, if you had time remaining on the original FusionDebug 1.0.0 license, this will also have expired.

To continue using FusionDebug 1.0.0, the FusionDebug 2.0.0 trial license must be activated. Once this is done, the original FusionDebug 1.0.0 license file can be re-installed and activated again.

If you later switch from 1.0.0 to 2.0.0, you can continue with your 2.0.0 trial license without problems.

The server configuration wizard

• tracks the changes that it makes,
• backs up the original configuration
• can undo the changes during an uninstallation.

If you are comfortable editing JRun’s jvm.config file, the change to enable FusionDebug is quite simple and can be performed in a few minutes. The Server Configuration Wizard simply provides a comprehensive graphical tool to accomplish the same thing.

Some classes of array data (notably binary arrays loaded from CFFILE tags) are truncated to 256-bytes in order to prevent Eclipse becoming unresponsive handling very large quantities of data. The ‘Expressions’ and ‘Variables’ views both update their displays to notify you when this truncation has occurred by appending “Truncated: showing 1 to 256 of X” where ‘X’ is the real length of the array.

The Inspect Expression popup also truncates this data but does not notify you when the truncation has occurred. This is due to a limitation of the Eclipse platform’s Popup mechanism. Once a tree element has been drawn, it is impossible to update it without re-displaying the popup, and for this reason the “Truncated” message is not shown.

FusionDebug can access any variables that are available in any server-side scope, for example Variable, Application, Session, Form, URL etc.

You should be able to find all of the values submitted on the flash form in the FORM scope of the Variable View.

Any CF page or code which runs through the ColdFusion engine may be debugged:

• Normal ColdFusion CFM, CFC, module, cfinclude or sub-tag pages
  • Sub-pages, including CFCs, modules and included pages will generate one frame each in the Debug View, allowing variables to be viewed for each frame, and which function, file and line number corresponds to the call
  • CFCs will also expose the special Function Local Scope (var, in cfset)
• Framework components
• ColdFusion code called from AJAX frameworks
• Flex CF code
• ColdFusion Asynchronous Gateway code
• .. etc.

The following code may not be debugged using FusionDebug:

• Native C or C++ CFX tags
• Java code,
• Java, COM, Web Service or objects created with cfobject
• JSP pages, or sections of CF pages which contain Java or JSP calls

The thread list in Debug View is in suspend order. The most recently-suspended thread appears last. Stepping a thread does not count as a resume for the purposes of ordering, and does not cause the thread order to change. Resuming a thread which later hits a breakpoint causes that thread to correctly reappear at the end of the list, since it has subsequently suspended on a breakpoint.

Although FusionDebug supplies this data correctly to Eclipse, Eclipse 3.1 sometimes changes the order of these threads. This behavior is not the case in Eclipse 3.2.1.

Since Eclipse updates contain a large number of stability, performance and functionality fixes, we recommend customers always use the newest Eclipse platform available.