A while back I sent some updates to the ColdFire ColdFusion debugger over to Ray Camden and today he published those updates. So what's new?
Well, I knew it was going to happen sooner or later. Yesterday I woke up to find about 100 messages in my inbox with links to my blog. Someone decided that using the "send" link on my blog entries would be a good way to get people to click on their low mortgage/cheap prescription drug/free porn links. So after over a year of not having to deal with spam on this blog I'm finally enabling captcha. Right now I think it is using the default, more complicated captcha images, but I'm going to look into setting up the simpler mode when I have the time. (I think this may even be a configuration option in later versions of Blog CFC.)
Under the hood ColdFusion 8 uses the Yahoo! User Interface Library (YUI) for a lot of its cool new AJAX UI elements. That is great news for CF developers because the YUI is very well documented and has lots of excellent examples. Using these examples and documentation we can easily extend the capabilities of ColdFusion's new AJAX components beyond what Adobe has built for us.
CF Debug Copy for FireFox now has a home on RIAForge. A download is available now and I should have the source code in SVN soon.
In preparing this release I noticed that the earlier version of this extension didn't work with frames. The version on RIAForge should fix that issue.
I'm also thinking about creating a RIAForge project for the IE version of CF Debug Copy. The only problem is it is currently a Visual Studio .NET 2003 project and I'm not sure how to best share it. If anyone has any suggestions on how to best store Visual Studio projects in SVN I'm all ears.
Due to a SNAFU at work yesterday I missed the Philly stop in the Scorpio Road Show. I'm disappointed because I had a few questions I wanted to ask Adam and Tim about the upcoming CF release. I was also looking forward to catching up with some of my former co-workers and other local CF develpers... Oh well, hopefully one of my fellow Philly bloggers will fill me in on what I missed.
Nice hotel, great sessions, even better people... I'm definitely going to try to make it back next year.
Since I've seen detailed post for most of the sessions I attended I won't try to do that here. I am going to list out the sessions I attended and try to pull out the key fact or impression I took away from each.
I manage several different instances of ColdFusion on several different physical servers. Each instance has its own CF administrator running under JRun's built in web server and while I have each bookmarked, I often forget which port number belongs to which instance on any given server. To help me identify which instance I'm currently working in I put together this basic instance identifier for the CF administrator. Just download the attached serverinstance.cfm and place it in your CFIDE/administrator directory. If you have an existing extensionscustom.cfm file in your administrator directory just add the following link:
If you don't have an extensionscustom.cfm file in the CFIDE/administrator directory create one with the above content.
When you log in to the CF Administrator you should now have a "Server Instance" link under "CUSTOM EXTENSIONS" in the left hand navigation frame. Click on the link to bring up a page identifying the JRun instance.
The code is from a Dev Center article by Brandon Purcell.
The other day I was building a quick demo of an application which used client variables for session management. On logout I was just doing StructClear(client) to clear the client scope. It has been awhile since I have worked on login code for a application which uses client variables for session management, but this is an approach you see used quite often for clearing variables in the session scope on logout.
Well, after logging out using this method I started to see the following error in the ColdFusion logs:
Some quick googling led me to comments in the ColdFusion Livedocs which in turn pointed me in the right direction. StructClear was actually deleting the "read-only" Client variables (CFID, CFToken, URLToken, HitCount, TimeCreated, and LastVisit) and this was causing the error. According to the Livedoc comments it is really only the HitCount variable which causes the issue, but the ColdFusion documentation does say:
ColdFusion lets you delete or change the values of the built-in client variables. As a general rule, avoid doing so.
Given this I updated my logout code to use the ColdFusion ClientVariable functions and all was well:
<cfloop list="#GetClientVariablesList()#" index="var">
<cfset DeleteClientVariable(var) />
I'm pretty sure I knew this at one point, but like I said it has been so long since I've done anything like this with the client scope I had totally forgotten about those ClientVariable functions.
If you are running multiple instances of ColdFusion you may manage those instances via the JRun Management Console (JMC). If you are on Windows and you installed a Windows service for each of your instances it is important to note that starting those instances via the JMC does not start the associated Windows service. Instead it launches the JRun instance as an application running under the same user the JRun admin instance (the "Macromedia JRun Admin Server" service) is running under.
Why might you care? Well, by default the JRun services run under the local system account. If you have modified your CF instances to run under another account via the Service Manager but left the JRun admin instance as is, you may run into issues when you launch your CF instances via the JMC. At this point they will be running under the the local system account, or whatever account you have your admin instance configured to run under, and that account may not have the permissions your instance needs.
What to do? One option is to always start the services using the Windows Service Manager. If your instances use different accounts this may be the only option short of launching JRun via the command line. If all of your instances run under the same account you may also be able run your admin instance under that same account. Instances launched via the JMC would then have the correct permissions even though the associated Windows service may not be started.
This was all observed in CFMX 6.1. I'd be interested to know if the same applies to the Enterprise Manager built into the CFMX 7 administrator.