Go to the license activation page and follow the instructions listed there.

This problem was reported against Fusebox 5.1

The issue is that there is insufficient Source Code Lookup data for FusionDebug to accurately place the breakpoint.

Often, the addition of a Source Code Lookup in the debug launch configuration tab is sufficient to get breakpoints firing reliably.

More help on getting breakpoints firing can be found in technotes below.

Highlight the name of the variable that you what to set/change the value of within an editor and then select the right-mouse click menu option “Set Variable”. In the dialog that opens enter a ColdFusion expression exactly as you would when performing a <CFSET> CFML tag. Note that a variable can only be set in a request that is currently stopped and you may have to use the scope of the variable to set the correct variable.

You can enter almost any ColdFusion expression as the value of a Set Variable (CFSET).

FusionDebug evaluates the expression like ColdFusion, which means that strings must be wrapped in double (“”) or single quotes(”) otherwise they will be interpreted as variable names.

<cfset myvar = "my string">
<cfset myvar = mystring>

Some examples of what you can enter in the dialog:

You can also create variables by using a scratch pad file where you enter the names of variables you want to create.

The Expressions View can handle most expressions which are valid in ColdFusion MX. A good rule of thumb is: if you can write it as an IF condition, on the right side of a CFSET assignment, or within “#” characters, it’s a valid expression.

Expressions are evaluated and re-evaluated only in the context of a suspended request. If no request is suspended, expressions are not evaluated. If a thread is suspended, try clicking on it. This will implicitly tell the Expressions View to re-evaluate its expressions for that request.

No. The port specified in the jvm.config (which defaults to 8000) should reflect an available port on your system, which then the FusionDebug configuration will point to, it is not releated to the web server or JRun.

This can occur when switching in the Debug View from FusionDebug to the Java application.

The expression which has been evaluated by FusionDebug is incorrectly assumed by JDT to be a Java expression. This is an issue with the JDT plugin, rather than a FusionDebug issue.

I’ve added the debugging settings required by FusionDebug to my servers configuration file /opt/jrun4/bin/jvm.config and now my server does not start any more.

When I start the server with

/opt/jrun4/bin/jrun start

I get the following error message:

Error [98] in bind() call!
<<<<<<< support.html
FATAL ERROR in native method: No transports initialized
err:: Address already in use
Socket transport failed to init.
Transport dt_socket failed to initialize, rc = -1.

This is caused by the attempt to start all servers sharing the same configuration (which is the default). The port number you have defined in the debug settings can only be used by one server at a time. Therefor either start only the server you want to debug, e.g.

/opt/jrun4/bin/jrun start cfusion

or use separate JVM configuration files for each server. Read the Adobe technote to get the details on how to do that.

This issue is caused by Eclipse’s own implementation of the Java Debug Interface (JDI) which does not accurately reflect the Sun reference JDI implementation. Because of the way Eclipse manipulates the Java classpath, any Eclipse application (e.g. FusionDebug) attempting to load a JDI implementation will reference the Eclipse classes, instead of the Sun implementation.

We have provided links to the relevant Eclipse bugs below.

Eclipse Issues

Problems with FusionDebug on Mac OS X can be reduced to two Eclipse issues:

• Eclipse supplies their own JDI implementation which is incompatible with the Sun JDI Specification (Eclipse Bug 101686)
• This issue may not occur on Eclipse 3.1 or earlier because it was masked by a classpath issue which has been subsequently fixed (Eclipse Bug 89111)
  • This is a Mac-specific bug with Eclipse’s classpath, which was set incorrectly and caused Eclipse JDT (normal Java) debugging to be unavailable. This would allow our supplied-JDI implementation to function correctly.
  • The fix for this issue (a correct Classpath which references the Eclipse JDI implementation) allows Eclipse JDT debugging to function, but unmasks bug 101686, which causes FusionDebug to malfunction.

Immediate Workaround

This workaround creates a second Eclipse bundle which does not use the Eclipse JDI implementation. This will unfortunately disable Eclipse JDT (normal Java) debugging, but will allow FusionDebug to function. The remainder of Eclipse properties (workspace, configuration, formatting etc.) will remain identical between the bundles. The original bundle can be used for JDT debugging, if required.

• Create a copy of your Eclipse installation with a modified classpath. This will make Eclipse find the Sun JDI implementation.
  • Locate your root Eclipse installation.
  • Within this folder, copy the Eclipse.app bundle, renaming the copy to EclipseFD.app
  • Open the EclipseFD.app bundle (Right click/Ctrl-click on EclipseFD -> Show Package Contents)
  • Navigate to Contents -> MacOS and edit the eclipse.ini file
  • Remove the line which begins -Xbootclasspath/p:../../../plugins/org.eclipse.jdt[…]
  • Save this file.

Caveat: This will disable JDT (normal Java) debugging within Eclipse. For this functionality, use the original Eclipse.app bundle.

If you are using a standard Eclipse install, or the FusionDebug standalone bundled IDE, but not Flex Builder, carry out procedure FDS – 92 linked below.

If this does not rectify the problem, you may need to alter the Lingon startup command for ColdFusion to include the Java options to enable debugging. The startup command should read as follows:

/System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Home/bin/java 
-server -Djava.compiler=NONE -Xnoagent -Xdebug 
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8777 
-Djava.awt.headless=true -jar /Applications/JRun4/lib/jrun.jar -start cfusion

N.b. this is all a single line. This Java configuration listens on port 8777 for debugging connections. Make sure your FusionDebug Debug Configuration within Eclipse reflects this in the connect tab.

The FusionDebug Eclipse Plugin installs its own launcher to enable starting Eclipse in the FusionDebug perspective.

If you have used the plugin launcher (the ‘red bug’ icon) to start Eclipse and then use the File->Switch Workspace function it does not restart automatically. Please manually restart Eclipse in this case.