Railo, Structures, Keys and Case

After hundreds and hundreds of development hours, Aaron and I are on the verge of releasing the completely rewritten InstantSpot to beta this week.  I plan on a more detailed post of the technology later, but in a nutshell, we are releasing it as a Linux/Apache2.2.x/Tomcat/Railo2/Mach-II application.

Until today, we have found only one place that we have had to make a Railo workaround and that was using some pretty fringe functionality doing XMLRPC for desktop blogging.

Last night I ran into the second point where we have to make a workaround, although from an architecture standpoint, again it is pretty slight.  This time, it came about as I was changing our Mach-II config to use the ColdspringProperty rather than the ColdspringPlugin.  When I did, the application died a horrible death with errors stating that it couldn’t find our imported ColdSpring XML files that are defined in our main ColdSpring XML.

After tearing into it this bit, I found that the DefaultXMLBeanFactory.cfc calls a recursive method to build a structure of the main config XML, with additional keys for each imported XML file which are the full physical path to the file itself.   I could see that just prior to adding to the structure, the case was correct.  However, when I look at the key that was created, it was converted to lower case.

Later in the process as the Mach-II ColdspringProperty.cfc tries to loop through these keys, the config files cannot be found if there are any capital letters that exist in the real path.

I then tried modifying the ColdSpring code to use structure bracket notation for adding the key, rather than using StructInsert(), since this is one known way of preserving key case in ColdFusion.  However, I found that no matter what I did, the structure key that is created is all lowercase.

Stepping back a bit, I decided to do a simple test which confirmed this functionality:


Here were the results:

number 3
number 2
number 1

As you can see, no matter which approach I took, the key is lowercase.

So, what does this mean for our release?  Not much… back to using the ColdspringPlugin.  However, it is something that I hope the fine developers of the Railo project keep in mind as a future fix.

Attention Mach-II developers… we need your knowledge!

Team Mach-II is looking for Mach-II developers that are willing to contribute writing of content to help build out the official wiki for the Mach-II Framework.  We have two general needs:

  • FAQ – Do you have some tidbits of helpful info that would help enrich the FAQ?  We would like to encourage the community to contribute and help us spread the word!
  • Documentation – If you have written or wish to create detailed write-ups targeted to specific features of Mach-II, now is your time to get them out there.

If you are interested and would like to know how you can get involved, please contact me at dave@mach-ii.com and we can discuss.

Creating the equivalent of IIS Virtual Directories in Apache

I have to admit that I used to be guilty of laziness on one aspect when I began using Linux/Apache a couple of years ago as a convert from Windows. I didn’t immediately understand how to create the equivalent of virtual directories in Apache that are available in IIS. I soon found that I could just do symbolic links at the file level that would effectively give me the same effect at the broswer request level. However, one big negative is that there is a linked directory sitting there in the parent directory, which is a pain in the tail when it things like source control such as subversion comes into play. When I browse to a directory in a terminal or my IDE, I don’t necessarily want to see it either. The answer is to use the “Alias” directive in Apache.


As a ColdFusion developer, I like to have a CFIDE directory available in my webroot as I develop so that I can access the ColdFusion administrator. I keep my CFIDE directory in /usr/local/apache2/htdocs/CFIDE.

To make that available as a virtual directoy, I need to add the following to my Apache virtual host definition:

Alias /CFIDE /usr/local/apache2/htdocs/CFIDE
<Directory /usr/local/apache2/htdocs/CFIDE>
Order allow,deny
Allow from all

Just remember to remove that one before you put it in production!

Interesting ColdFusion error with extended CFCs and Mixins

Many moons ago we experienced some behavior that we had a hard time pinpointing regarding CFCs with CFINCLUDES.  There is even a blog entry about it on here somewhere that is probably a year or two old.  In essence we were seeing some things that indicated that ColdFusion didn’t really see the CFC as a whole object.  We found a quick workaround at the time, and it faded from our memory never to be pursued.  I came across it again today and combined with past experience and bit more patience I think I have nailed down the problem.

For background, we use the spectacular Illudium PU-36 by Brian Rinaldi to generate most of our objects.  Since things change during development time, it was sucking to have to re-add in any customization we made to our CFCs if we had to regenerate them.  Our solution was to modify the XSL so that in each package, there is a “_includes” folder.  We would then add a <cfinclude /> at the bottom of each CFC to include any custom methods so that we could regenerate the CFCs at well. For instance in a “Foo” package, the structure would look like this:

  • _includes
    • Foo-cfc.cfm
    • FooGateway-cfc.cfm
    • FooService-cfc.cfm
  • Foo.cfc
  • FooGateway.cfc
  • FooService.cfc

This was worked without flaw for us for some time now, and in fact the entire new architecture of the soon-to-be-release InstantSpot 2 is built in that fashion.

However, in that environment we were doing no extending of objects and no method overloading.

While working on a client application today I was building something that looked like this:

  • _includes
    • ParentFoo-cfc.cfm
    • ParentFooService-cfc.cfm
  • ParentFoo.cfc
  • ParentFooService.cfc
  • FooChild1Package
    • _includes
      • FooChild1-cfc.cfm
      • FooChild1Service-cfc.cfm
    • FooChild1.cfc
    • FooChild1Service.cfc
  • FooChild2Package
    • _inlcudes
      • FooChild2-cfc.cfm
      • FooChild2Service-cfc.cfm
    • FooChild2.cfc
    • FooChild2Service.cfc

What we have found is a situation like this…

Say that the FooChild1 object has a method called doStuff() which is included by FooChild1.cfc and it is intended to overload the Foo object’s parent doStuff() method.  When the objects are being instantiated, an exception is thrown saying that you cannot have two methods named the same in an object.  I can’t tell you why, but somehow in the way that ColdFusion is compiling, it just doesn’t know how to process that overloaded method in a cfinclude.

The workaround is plain and simple, in that all we had to do was kill the includes and move the methods inside the actual CFC.   To be specific, we could leave the include in the parent, but not the child.  Of course, now we will need to pay a bit of attention as we regenerate our objects, but due to the extensions they were pretty far from stock anyway.

For the record, we have seen this behavior in both CF7 and CF8.   I realize this is probably a fringe case to most, but I wanted to throw it out there in case anyone else stumbles across the same issue.