Rob's Ramblings

A legacy application I maintain uses Verity, and is being moved from a CF7 server to CF9. We do not have the approval to upgrade it to use Solr at this time.

My development environent is Snow Leopard. I have CF9 Developer Edition installed clean on it. The installation never gave me options for setting up Verity. So imagine my surprise when I find that Verity is not installed in my CF9.

After asking around some, I did some digging myself. I think there might be an issue with the OS X installer that could explain this.

I opened the Adobe_ColdFusion_9_InstallLog.log file, and searched for verity. I found this line:

"Install File:             /Applications/ColdFusion9/WEB-INF/cfusion/lib/verity.jar"

Looking in my /Applications/ColdFusion9/ directory, there is no WEB-INF/cfusion/lib directory. I found the verity.jar file in /Applications/ColdFusion9/lib/.

So putting this together, it looks like the installer is looking in the wrong place for this?

This brings me to two questions:

1. How do I report this to Adobe?
2. Can I manually install this verity.jar file? I have no experience in that arena, would need to be handheld through it.

Any help is appreciated.

Comments are moderated solely for spam-prevention purposes only.

Adobe released CFBuilder to the paying public, as we all know. And it looks like they fixed quite a few things from the last beta. But they also broke one thing, and it's a real bother.

As of this official release, you no longer can manually install CVS into a standalone installation of CFBuilder. In teh betas, you could do this via the Eclipse 3.4 update sites (noted in this blog post). Now, it generates an incompatability error.

UPDATE: The fix to this was to use the correct update site for Eclipse 3.5. The site to use is http://download.eclipse.org/releases/galileo/. I had been using http://download.eclipse.org/eclipse/updates/3.5 and that was incorrect. Thanks to Nathan Mische for pointing this out to me!

Comments are moderated for this blog solely for spam-prevention purposes.

This post is one of those where I am hoping somebody can provide me with some assistance.

I have been using CFBuilder on Snow Leopard for months now. I love it. I especially love the server consoles, the tailview, and the RDS services. The only thing I have not loved about it are the occasional crashes, but I expect it from beta software.

In the last week however, they have become more than occasional. They have become regular. CFBuilder constantly is hanging, eating up all of my CPU, and giving me constant Java Heap Space errors. Ususally it's trying to build project settings or index projects, and I can let them go on for literally hours at a time and nothing will happen. I've had to Force Quit CFBuilder numerous times now.

I went so far as to uninstall it and do a fresh install, no avail.

If anyone has some things that could help me, I would be appreciative. I'm back using CFEclipse, and it's just not the same for me.

Please note that all comments are moderated for spam-prevention purposes only.

Okay, the title is meant to be facetious, and attention grabbing. Just so we're all on the same page. But it's not untrue.

Through Ben Nadel's fantastic blog, I learned the practice of creating and scoping a LOCAL struct in a CF function (CFMX7 and CF8), and assigning any other local variable created in the function into that struct. That way I did not need to manage multiple variables, trying to make sure they were all locally scoped. It seemed more efficient.

Well, with the migration of my VPS to CF9 (and the impending upgrade of my work's servers to CF9), I found blog posts talking about how others that had used this practice were finding oddities with their code upon upgrading. It seems that this practice was somehow colliding with the new protected "local" scope within functions in CF9. The new scope allows coders to do exactly what I was doing, only without having to scope that local struct first.

In trying to figure out what changes I needed to make, I went asking around trying to find out if this meant that we no longer had to scope local variables anymore inside of functions, if unscoped variables would automatically get put in the new local scope. To hear and read the documentation, you certainly could come to that conclusion.

Thanks to Ray Camden, I have been straightened out. It turns out this is not the case, and I am not the first to ask him this. He was kind enough to make this topic an entry in his just as fantastic blog.

Bottom line, you don't have to scope things put in the local scope, but you must explicity call the variable in the local scope (local.myVariable). And all other variables must still be scoped for protection.

On a legacy application that I maintain, I have seen a rash of errors recently that are new. They are all in regards to form fields missing on a form action page. The things that make this one different is that:

1. The fields in question are empty text fields, not unchecked radio buttons or checkboxes.
2. The browser type of all these errors in Google Chrome

Now, while the fix is the same for all of these issues (CFPARAM the form fields), I was wondering if others have been seeing this with Chrome at all, and if there's any insights as to why Chrome seems to not want to pass along empty text fields, like every other browser out there does. I have not played with Chrome at all, and our applications do not officially support that browser at this time, so I can't spend much time at all investigating these errors in light of that. So I am hoping that some of y'all might have some information you would be willing to share?