BarneyBlog

So, BD 6.1 Beta solved most of my problems with CFCs. I'm on cloud nine, and I'm finally getting some work done. It's not perfect, but none of the other bugs were really more than inconveniences (for instance, it gets grumpy when you mix full CFC paths with pathless references to CFCs in the same package). No big deal, just figure out what the issue is, and work around it (always full-path everything, in this case). Plugging away, and I've got the backend of my app finally put together.

Now it's time for the front end. Throw the Fusebox 4.1 skeleton app in there and run it. Error about indexing 'attributes' as an array, trying to set the default fuseaction. Refresh. No issue. WTF? Refresh, fine. Refresh, fine. Touch the code, refresh, error. An hour later I've isolated the problem. Scope leak on a CFLOOP tag iterating over a query.

We all love the fact that CFML lets you reference the fields of the current record of a recordset you're looping over with just the column name. Once you stop the loop, that stops functioning, and you have to again fully scope the field you want (queryname.columnname[row]). BD was doing that, but if you raised an exception inside the loop, it never bothered to turn off that special psuedo-scope. Which meant that for the remainder of your request, variables in the VARIABLES scope that happen to have the same name as a column in the query you were iterating over are shadowed, just as they were inside the CFLOOP.

And of course, 'attributes', that wonderfully versatile, utterly indispensible Fusebox scope is the problem in this case. The loader runs a CFDIRECTORY tag and loops the result, potentially throwing an exception. And guess what, there's a column called "attributes" on queries returned from CFDIRECTORY, so any time it throws that exception, the request fails. (As an aside, the exception in question is an internal exception that the core files use for their internal functioning. It never sees the light of day, except in the CFMX debugging output, if you have the exception list turned on.)

Fortunately, that exception will never be raised in production environments, it's part of a development-mode-only feature (the conditional loader), so no apps are going to break. But it makes development rather difficult, as you might imagine.

So my problem from last night where CFCs wouldn't work on the URL turned out to be a conflict between CFMX and BlueDragon. I don't have CFMX installed on my box any more, but when I uninstalled it, it left a couple Axis config files in a WEB-INF directory. BD, being the well-behaved J2EE application that it is, was trying to use them, rather than it's own, because it assumed they were placed there intentionally to override it's internal ones. Just a simple matter of deleting those files and problem gone. Yay!

I do have to give NewAtlanta props for being on the ball getting issues like this resolved. One of their engineers figured out exactly what the problem was for me, with no input from me except a copy of the error message (and that routed through a couple other people), and within a matter of hours, I had a description of the problem, how it happened, and how to solve it. This is the shining example, but for pretty much every problem I've had, I've gotten a personal response back with either help to resolve it, or at least confirmation that it's a bug, and that it's now known and will be fixed.

I was just about to come say how happy I am with BlueDragon 6.2 in comparison to how I was two weeks ago. I've had great success working with my framework and getting it moving along nicely. But, then I started on the frontend of a project I've been working on separately, and ran into another show stopper. The UI is [going to be] built using Rob Rohan's Neuromancer, and consequently need to make some web service calls to my facade CFCs. Unfortunately, BD doesn't want to do that, it just throws a big nasty Axis fault for both ?wsdl requests and for the "my.cfc?method=myMethod" means of calling CFCs for "normal" page handling.

So here I am, once again smashed up against the almost functional BlueDragon. I suppose I should just assume that nothing works, and test every bit of functionality before planning to use it, but that seems like such a back-assward approach. Oh well.

I've been continuing to work with BD 6.2 beta, and having pretty good success. There have been a pretty substantial number of bumps along the way, but none of them have been show stoppers, and it is a beta offering, so it's not supposed to be perfect. All in all, things are going well.

Then I went to upgrade my server (the one running this site). Oof. Tried uninstalling 6.1. Failure. Tried reinstalling 6.1. Failure. Tried deleting all the 6.1 crap (including that pesky /usr/local/NewAtlanta/.registry file) and reinstalling 6.1. Failure. Tried downloading the 6.2 beta from New Atlanta's web site. Error because they have some weird HTTPS -> HTTP transition that lynx and w3m can't deal with. Tried their FTP server. Not accepting connections. Tried downloading it to my laptop, and then uploading it to my server. Corrupted archive. Try downloading it on my linux box at home to upload. Won't go past ~6MB. Try again. Same result. Try to start a session on my powerbook and hijack it with lynx after the HTTPS -> HTTP transition. Denied. Try the FTP server again, and it thankfully lets me in. No ls command though. Finally figure out I have to switch from passive to active FTP and I can do 'ls'. Download the beast.

45MB later…. Delete all my 6.1 stuff from the several installs (backing up my config, of course). Run the 6.2 installer. Like a champ. None of my sites work though. Cycle BD and Apache. Still nothing. Run a ps auwx | grep java on there, and to my surprise, I've got 5 independant BD processes running!! Manually kill everything, restarting BD, and viola!

So now that they've got the CFC bugs worked out, definitely time to spend a little effort on the start/stop scripts and the install/uninstall procedure. Fortunately that's stuff that I don't use much, so it won't really bother me if they don't.