<cfset this.mappings["/myapplication"] = expandPath("../")>

See the bug there? ExpandPath() is relative to the requested template. This application had previously had all requests routed through /public/index.cfm so the mapping worked fine.

However, recently we had added some new web services like /public/services/ScheduleService.cfc and now whenever an Ajax request went through the CF mapping would change from pointing to / to /public causing all other concurrent requests to fail with confusing missing file errors.

I fixed this by making sure the path was no longer relative.

<cfset this.mappings["/myapplication"] =
   getDirectoryFromPath(getCurrentTemplatePath())>

So the moral of the story is to NEVER use expandPath() to create a mapping that’s relative to the webroot.

<cffunction name="test" myAttribute="1">
  <--- How can we get the myAttribute value? --->
</cffunction>

The first obvious attempt at this is to use getMetaData(test).myAttribute, and that works fine until you pass the function as a pointer and then it’s not called test anymore. Instead we need a different way to get the current function.

I had looked into this for implementing closures some time ago, and even talked about this at BFusion 2008. My original workaround was to create an API around the function pointer. For example executeFunction(func) that passes the function pointer in as an argument. Unfotunately, this also means you can’t just pass this function around transparently to anything that expects a function pointer.

Last night, however, I had a eureka moment and figured this one out. To get a reference to the current function we’re going to harness exceptions and the information we can get from the stack.

<cffunction name="getStackFunction" access="public" returntype="any" output="false">
   <cfargument name="name" type="string" required="true">
   <cfargument name="depth" type="numeric" required="false" default="1">

   <cfset var TemplateClassLoader = createObject("java","coldfusion.runtime.TemplateClassLoader")>
   <cfset var servletContext = getPageContext().getServletContext()>
   <cfset var templatePath = "">
   <cfset var TemplateClass = "">
   <cfset var field = "">

   <cftry>
      <cfthrow type="Exception">

   <cfcatch type="any">
      <cfset templatePath = cfcatch.tagContext[depth+1].template>
   </cfcatch>
   </cftry>

   <cfset TemplateClass = TemplateClassLoader.findClass(servletContext,templatePath)>
   <cfset field = TemplateClass.getDeclaredField(arguments.name)>
   <cfset field.setAccessible(true)>

   <cfreturn field.get(TemplateClass.newInstance())>
</cffunction>

We can then use this code with the (case sensitive) name of the function in the current stack to get a pointer to that function.

<cffunction name="test" myAttribute="1" output="false">
   <cfargument name="x" type="numeric">
   <cfset arguments.callee = getStackFunction("test")>
   <cfreturn arguments.x + getMetaData(arguments.callee).myAttribute>
</cffunction>

You can use the depth parameter to get functions farther down the stack as well.

I’ll go over how to build proper closure constructs using this technique, and some other novel ones that don’t even require runtime magic in an upcoming post.

Oh, and hats off to Ben for sparking my interest in this issue again! :)

This seemed to cause file locking issues in cfimage which I was told were addressed by CF 8.0.1 Cumulative Hot Fix 1. I applied the hot fix and everything seemed to work, but then when I started testing with the large file again the CPU would jump to 100% and the request would never seem to finish. I tried all kinds of things, and nothing I did seemed to make a difference.

Finally I tried the “highestPerformance” interpolation and the requests started finishing hundreds of times faster. Any other interpolation algorithm seems to cause the thread to lock up.

I’ve fixed this in our code with:

<!---
	CF8 will peg the CPU to 100% and this thread will seem
	to hang for minutes on large images if we don't choose
	highestPerformance.
--->
<cfif getSize("kilobytes") gt 375>
	<cfset arguments.interpolation = "highestPerformance">
</cfif>

What’s most odd is that the issue only appears on Windows on the production server. On my Macbook I can choose a different algorithm and get a nice resize without hanging the request.

Production server is Java 1.6 u11, CF8.0.1 HF2, Windows Server 2003

Anyone have any ideas?

So CF8 outputs the cfcatch.message into the Reason-Phrase portion of the HTTP Response, however it does not strip new lines (LF or CR). A web server, however, should never send new lines in the Reason-Phrase [1], and should probably be truncating that error message at a certain length.

[1] RFC2616, Section6, HTTP Response

It’s pretty easy to reproduce this bug:

<cfthrow message="foo #chr(10)##chr(10)##chr(10)# bar">

Another way to show this is with the new deserializeJSON() function in CF8 when the JSON is not valid. CF outputs the exception message with the JSON into the Reason-Phrase portion of the HTTP response Status-Line without stripping out new lines.

ColdFusion Code

<cfset json = '
{
    "foo": [
        {}
        "",
        {
            "f": {}
        }
    ]
}
'>

<cfset deserializeJSON(json)>

And the server responds with:

HTTP Response

HTTP/1.1 500 JSON parsing failure: Expected ',' or ']' at character 20:'"' in {
	"foo": [
		{}
		"",
		{
			"f": {}
		}
	]
}
Date: Wed, 01 Aug 2007 05:31:39 GMT
Server: Apache/1.3.33 (Darwin) mod_fastcgi/2.4.2 PHP/5.2.0 JRun/4.0
server-error: true
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

<!-- " ---></TD></TD></TD></TH></TH></TH></TR></TR></TR></TABLE></TABLE>

As it stands now, if you had 100 lines of JSON and there’s an error at the end, CF will dump all previous lines of JSON into the http Reason-Phrase.

This is particularly apparent in Safari (and WebKit based browsers) where it actually displays the HTTP headers in the body of the page because it sees new lines and assumes the HTTP headers are complete, and worse in Gecko based browsers that render the page as text/plain because the Content-Type header is never processed!

It should also be noted that CF7 output “Internal Server Error” for the Reason-Phrase instead of the exception message.

There also seems to be some other random junk thrown into the page when an exception is thrown….

foo bar baz<cfthrow message="foo #chr(10)##chr(10)#bar">

Will generate the following right after the http headers:

b
foo bar baz
1f27

I hope this saves someone some time trying to figure out what’s going on on their code! :)

Ben Nadel noticed some of this odd behavior as well.

I spent a long time trying to figure out how to get the caller template path, including what Ben did which was to add a special function to the caller scope.

<cfscript>
function getCallerTemplatePath() {
    return getCurrentTemplatePath();
}
caller.getCallerTemplatePath = getCallerTemplatePath;
path = caller.getCallerTemplatePath();
</cfscript>

This doesn’t work though. Instead I still got the template path of the custom tag!

I dug around in the PageContext (which is returned from getPageContext() if you’re not familiar) with no luck and finally gave up resorting to this…

/**
    Monumental hack, but the only way I could figure out how to do
    a getCurrentTemplatePath() like call that resolves to the page
    that called this custom tag.
*/
function getCallerTemplatePath() {
    try {
       error;
    } catch( any cfcatch ) {
        return cfcatch.tagContext[3].template;
    }
}

Which worked but really felt like a hack since it means throwing an exception on every request. So I kept an eye out as I dug around in the internals of the CF engine for various other things, and today I was rewarded with an awesome solution.

/** Gets the path to the page that called this custom tag. */
function getCallerTemplatePath() {
    var field = getMetaData(caller).getDeclaredField("pageContext");
    field.setAccessible(true);
    return field.get(caller).getPage().getCurrentTemplatePath();
}

Now to get at why and how this kind of thing works…

Inside the ColdFusion runtime the foundation unit for all scripts, components and tags is the coldfusion.runtime.CFPage object, and the getCurrentTemplatePath() function is really identical to…

function getCurrentTemplatePath() {
    return getPageContext().getPage().getCurrentTemplatePath();
}

After realizing this it dawned on me that the custom tags, cfcs, and pages all have their own PageContext and Page objects, and as such the template path is going to be different, or rather bound, to the page in which the function is called from, not where it’s defined.

Knowing this I was able to grab the page context out of the caller scope, which is the page context of the caller, and not the current page, and use that to get the current template path of the page for which that page context operates.

Also, for those who aren’t familiar, the getMetaData() function can be used to return the java.lang.Class instance for most objects you wouldn’t normally be able to call getClass() on in ColdFusion. For instance you can call getMetaData(variables).getName() and you’ll get coldfusion.runtime.VariableScope.

Doing this really made my code feel less icky, so I hope this is useful to someone else.

(PS, Tested and works on CF6+ and CF7+, anyone have CF8?)

PList XML is particularly problematic because of how its structured:

    <dict>
        <key>Foods</key>
        <array>
            <dict>
               <key>Chocolate</key>
               <true/>
            </dict>
        </array>
    </dict>

While this example is contrived we can see that keys are associated with the following element in dict[tionaries] and that array elements are just the elements inside array blocks. This makes tools like XPath less than stellar since nodes don’t have real ids and makes working with E4X awkward.

Instead I decided a layer of transparency would be best, so the previous structure could be represented as:

    Dictionary {
        "Foods" => Array [
              Dictionary {
                   "Chocolate" => true
              }
         ]
    }

The goal being that in the actionscript I can do myPlist.Foods[0].Chocolate and get true, and allow simple assignments so myPlist.Foods[0] = "foo" should automatically wrap that string in a PListString. Simple right?

Well in a language like ruby, yes, but AS3 makes it more complicated than it needs to be (in part due to the way ECMAScript works) and requires flash.utils.Proxy to be able to override the Array Access operator.

This is problematic as it means that PListArray cannot actually extend the Array class and still override the Array Access operator at the same time! Doh!. To add insult to injury the array access operator definition on the Array class doesn’t call a method that we can override.

This means making a Typed array that handles all input and output to allow wrapping is impossible, instead we’d need to resort to get() and set() methods which means you can’t actually use the PListArray in any method that requires an array in transparent manner.

This makes me question why Adobe chose to force a fragile base class on us for overriding the existing object operators like delete or the Array Access Operator.

Instead they should have used an interface, flash.utils.IProxy which allowed implementing methods for calling performing those actions. Then again we’re still in a bind since interface methods must all be public these new override methods would clutter the public API.

Seems to me the best solution would be a little syntax addition for array access such as:

function object get():*
function object set( key:*, value:* ):void
function object delete( key:* ):void

And so on…

This would allow defining proper getters and setters for the array access and let users redefine the getter and setter methods on superclasses to implement proper Arrays without the need to extend a super class which may or may not be an option. Sweet too since we can do this without even extending the language by adding an “object” namespace. :)