Rob Brooks-Bilson

Last week, I upgraded one of my company's server clusters from CF 5 to CF MX. The install went fine. However, when I tried to apply updater 3 to both servers, it worked fine on one of them, but refused to install on the other.

I tried everything I could think of (initially) - I stopped all of the CF and IIS services ahead of time. I rebooted and tried again, nothing. Finally, I opened the task manager and noticed that an instance of jrun.exe was still running, even though I had stopped all CF services. Highlighting it and clicking End Process had no effect - I just got an access denied error message.

I was finally able to resolve the issue by setting all of the CF services to manual and rebooting the server. Once I did that, the jrun.exe process was no longer running and I was able to complete my updater 3 installation with no additional problems.

I'm traveling next week, so I most likely won't be blogging anything new. I'm headed back to the East coast to upgrade a cluster of CF 5 servers to CFMX (among other things). Should be fun...

The other day, Sean Corfield pointed to a Design Patterns site that contained listings for several of the more popular design patterns. Code samples for C# were provided for most of the patterns. Sean closed his blog entry by asking if the CF commnunity might be up to the challenge of creating a similar site for design patterns in ColdFusion MX.

After a discussion with Brendan O'Hara, the author of the monthly Design Patterns column in the ColdFusion Developer's Journal, we decided that this would be an excellent idea. I've offered to host the content as part of the CFCZone.org (this ties in nicely with the site as most design patterns are implemented using CFCs). Brendan's offered to contribute some of the initial content based on the articles he's written so far.

What I'd like to propose next is an open call to the ColdFusion community to contribute as well. What is it we are looking for? Well, for starters, we need to define how we want to structure the offering. Obviously, we don't want to copy the same format as the Data & Object Factory site. We need to come up with an original way of presenting the design patterns in a way that makes sense for ColdFusion. The second thing we need is for developers with an understanding of design patterns to author the actual content. Brendan's offered to start things off, but we'll need the support and talent of several developers if this is going to work.

Fell free to add your suggestions via the comment link, or email me directly at admin@cfczone,org.

In ColdFusion 5 (and older versions), you could use the CFREGISTRY tag to lookup the location of the ColdFusion install. This was a handy feature - especially if you wrote ColdFusion code to deal with files and directories under the ColdFusion root (not the web root) and didn't want to hard code the values.

In older versions of ColdFusion, the default install location was c:\cfusion. In ColdFusion MX, it's c:\cfusionmx.

Because CF MX no longer uses the registry to store configuration information, you obviously can't use CFREGISTRY to lookup the install location. There is, however, a new server variable that you can use instead:

SERVER.COLDFUSION.ROOTDIR

This variable gives you the full path to the ColdFusion root directory.

I made some major changes to my blog today that should make it much easier for me to keep updated. Here's a breakdown:

• Switched from Blogger to a ColdFusion blog written using CFCs. The blog is based on Raymond Camden's blog.cfc. Thanks Ray!
• Updated the RSS feed for the blog
• Added ability to search the blog
• Added a commenting system
• Added linkable categorization

Keep an eye out for a lot more new content here as I plan to start updating my blog on a much more regular basis.

It appears as though ColdFusion MX has introduced a new bug with the CFDEFAULTCASE tag. In previous versions of ColdFusion (CF 5), the following code was valid:

<cfset x=5>

<cfswitch expression="#x#">
<cfcase value=1>
x is 1
</cfcase>
<!--- the defaultcase statement causes the problem --->
<cfdefaultcase />
</cfswitch>

As of CFMX, the CFDEFAULTCASE tag with the trailing slash causes the following error:

Invalid CFML construct found on line 19 at column 18. ColdFusion was looking at the following text: />

The CFML compiler was processing:

a cfdefaultcase tag beginning on line 8, column 4. a cfdefaultcase tag beginning on line 8, column 4.

Of course this is easy to work around - just don't use the CFDEFAULTCASE tag the way I've shown above. However, this makes me wonder whether CFMX has problems with other tags that are coded with the trailing slash. I know that CFMODULE works ok, but it would be interesting to test other CFML tags to see what happens...

IBM recently released JTOpen 3.3, an open source JDBC driver for connecting ColdFusion to DB2/400. Believe it or not, I'm not the only person out there using DB2/400 as a backend database. Anyhow, you can download the latest version from http://oss.software.ibm.com/developerworks/opensource/jt400/downloads.html. Note that registration is required.

Greetings on the official first day of sessions at Macromedia DevCon 2002. Things have been going well so far. Rather than go on and on, I'll give you the highlights (at least for me):

• Wireless Internet Access! There are several open access points setup throughout the conference area where anyone with an 802.11b card in their laptop (or other device) can connect anf get high speed Internet access. Kudos to Macromedia!
• Networking. I can't say this enough. If I take nothing else away from this conference (don't worry, I will), I can say that without a doubt, I've met some of the most fantastic people in the ColdFusion community. Things started at yesterday's CF_Underground 4, organized by Michael Smith and his crew and progressed through the night with Macromedia's Welcome Reception, followed by more schmoozing at Kimono's with a great group of developers. For me, the night wrapped up over at the House of Fusion's Community Suite, hosted by Michael Dinowitz and his group.
• This mornings keynote was good, but I do have a few comments. Having attended all three previous Allaire/Macromedia DevCons, it was a little sad to see some of the attention taken away from ColdFusion and given (understandably) to Macromedia's other products. While I totally understand this (after all, Macromedia does have a full, integrated product line), it made me a little nostalgic for DevCon's gone by. That said, the keynote did a good job of showing how Macromedia has evolved over the years. I'm looking forward to tomorrow's keynote more, however, as I'm really hoping Macromedia will give us more of a glimpse of where they are headed in the future!
• Speaking of glimpsing into the future, there's a lot of buzz over macromedia's previews. What could they be??? I wonder...
• I gave my first session today - UDFs in ColdFusion MX. It went fairly well, although I had some technical difficulties with the projector, needed to borrow a mouse (long story), and really needed more than the alloted 60 minutes to deliver everything that I had to show. All in all, it was ok, but I would have liked it to have gone a little better.

There's still a lot of great stuff happening tonight. There's an event for meeting Team Macromedia members (of which I am one) as well as Coldfusion User Group Managers. With so much to see and do here at DevCon, you could never leave the hotel, and still not be board. More later...

I'll be in sunny Florida all week (including today) attending Macromedia DevCon 2002. If prior Allaire/Macromedia conferences are any indication, this year's conference should be fantastic. Besides the excellent technical presentations, DevCon is absolutely the best networking opportunity for ColdFusion developers.

If anyone is interested in meeting up, feel free to drop me an email at rbils@amkor.com. Alternately, I'll be hanging around at various events throughout the week (Macromedia Community Connection Room, CF Underground 4, Meet the Authors Event, etc.). Check back for regular updates throughout the conference. If I get the opportunity, I'll try to upload some pics of each day's events.

I'm not sure if anyone else has already blogged this or filed it as a bug with Macromedia (I went ahead and filed it today), but there's a bug in the CFIMPORT tag when trying to import tags from a directory that's outside the web root directory. Normall, ColdFusion allows you to create mappings just for this reason--so that you can have tags like CFINCLUDE get files from outside the webroot withough having to expose those templates via URL. Basically, CFIMPORT is ignoring any mappings you set in the ColdFusion Administrator.

For example, if I create a directory for my custom tags that's outside of the /wwwroot (and not under the /web-inf directory), CFIMPORT ignores the mapping. So, the following code fails assuming my webroot is e:\inetsrv\intranet\wwwroot and my mapping is to e:\inetsrv\intranet\web-sys

<cfimport prefix="ui" taglib="/web-sys/customtags/ui">

The error I get is that:

Could not import the tag library specified by /web-sys/customtags/ui. The following error was encountered: E:\inetsrv\intranet\wwwroot\web-sys\customtags\ui

Now, if I put a template in that same directory and CFINCLUDE it, it works fine. This tells me that there's a bug in CFIMPORT seeing the mapping.

There are two "workarounds" to this. The first is to put the tags you want to import into the WEB-INF directory. I prefer not to do this because this is a directory CFMX creates in it's own directory structure, and it's location will vary depending on where you install CFMX. I'd also hate to see CFMX overwrite any of my files or directories at a later point.

The second workaround is to create the mapping in the jrun-web.xml file in addition to the CF Administrator like this:

<virtual-mapping> <resource-path>/web-sys</resource-path> <system-path>E:/inetsrv/intranet/web-sys</system-path> </virtual-mapping>

That works, but is obviously a problem for applications that need to be easily deployed to different servers and environments. I shouldn't have to manually edit a CFMX config file. Hopefully, this is something that's easy for Macromedia to fix and can be included in the next CFMX Updater.