Showing posts with label ColdFusion 10. Show all posts
Showing posts with label ColdFusion 10. Show all posts

Friday 25 October 2013

Adobe backtracks on no-support for ColdFusion 10 on OSX 10.9

I mentioned this the other day: 'So there won't be support for OSX 10.9 "Mavericks" on ColdFusion 10'. I just checked the bug tracker, and ticket 3653076 has now been marked "To Fix". Hopefully they mean "for ColdFusion 10" (and, realistically, they should fix it in CF9 too, as it's still a supported version of ColdFusion), not just for ColdFusion 11.

Good work to two groups of people:
  • the community, for rounding on this issue and making their voices heard. The ticket's only existed for three days, but it's got 33 votes and 20 comments. That's very active for a ColdFusion issue;
  • the Adobe ColdFusion team for seeing sense in this matter.
Yay everyone!


Thursday 24 October 2013

So there won't be support for OSX 10.9 "Mavericks" on ColdFusion 10

There's been a huge flurry of activity on the ColdFusion Bug tracker around ticket 3653076, entitled "Bad apache / tomcat connector for Mac OSX Mavericks 10.9". It was raised two days ago and has 20 votes already, and 13 comments.

And Richard Herbert has just done the decent thing and reminded us all that Adobe have already officially responded to this...

Wednesday 23 October 2013

Documentation for older versions of ColdFusion

Gavin was asking about docs for older versions of ColdFusion today. In my searchings, I've located the docs for a number of older versions of ColdFusion. I'm gonna list 'em here so they're easier to find.
  • Cold Fusion 2.0 online documentation, courtesy of GES technologies (update 2015-05-07: link is now dead)
  • Cold Fusion 3 online documentation, courtesy of House of Fusion (update 2016-06-30: link is now dead)
  • ColdFusion 4.5 online documentation, also courtesy of House of Fusion (update 2016-06-30: link is now dead)
  • ColdFusion 4.5.2 offline downloadable documentation, courtesy of Adobe (these are zip files)
  • ColdFusion 5.0 offline downloadable documentation (Adobe, zip files)
  • CFMX 6.1 offline downloadable documentation (Adobe, zip files)
  • CFMX 7 offline downloadable documentation (Adobe, zips)
  • ColdFusion 8 online documentation (Adobe livedocs)
  • ColdFusion 9 online documentation (
  • ColdFusion 10 online documentation (the current rendition of Adobe online docs: I wish they'd just stick with the same bloody domain name / online docs structure!!). That site is now dead. But the docs are here: ColdFusion Documentation Archive.
  • ColdFusion 11: same page as above, but that's a direct link.
Hopefully that's helpful to someone.



    Wednesday 25 September 2013

    ColdFusion: Latest from Adobe on the getParameter() thing

    Just noticed this new comment on 3222889:

    Of course the method is there since it is part of the interface. It is just that the call for getParameter('param') is returning null and we will have to debug Tomcat source to understand that. This object is coming from Tomcat and we don't have any control on it and hence we can't do much about it.
    However, I am curious to know the scenarios when you would like to use it. We anyway provide you the Form scope through which you would get all the request parameters. What would be the scenario when you would not want to use the Form scope and use the getParameter method of the request object?
    We exposed the API to get the underlying application server's pageContext object and we are giving that. But if some method on that object is not working correctly, it would certainly be not a bug with ColdFusion, would it? 

    This kinda conflicts with Micha's findings about the same, doesn't it?

    I'd also like to point out that this has already been explained in comments against the ticket. However it would of course require Rupesh to pay attention to them.

    But fair's fair: there's not a huge amount of detail from Damon there. I will touch base with him and see if I can get a better understanding of what's going on, and why he needs this, and replicate it here.

    And now I have a day job to attend to.


    Tuesday 24 September 2013

    Things I dislike: jobsworths


    For non-UK-English-speakers, from Wikipedia:
    A jobsworth is a person who uses their job description in a deliberately uncooperative way, or who seemingly delights in acting in an obstructive or unhelpful manner.

    I started to have a quick look at ColdFusion 10's new ESAPI functions this morning...  I'd give you a link for those, but they don't seem to be categorised in the docs (and I can't annotate the docs accordingly, cos the site is still broken since it was "upgraded" to use the new wiki)... and quickly got deviated onto the bug tracker.

    Monday 26 August 2013

    The process of creating a clear repro case for a bug: <cfchart> vs Async CFML gateways

    It's bank holiday Monday and it's gloriously sunny outside, but for some reason I am investigating a bug I didn't even know existed nor would ever be likely to encounter. I'm a dick.

    Thursday 22 August 2013

    Tuesday 20 August 2013

    CFML: evaluate(): CFMX7 and CF10 compared

    A few days ago I had a look at this - apparent - myth that evaluate() is terribly terribly slow and one should not use it on that basis alone (not forgetting there's no real justification to use it these days anyhow). I tested on ColdFusion 9 and 10 to gather my results (the final results posted were from CF10, but the two were much of a muchness). I speculated that given there was not really good-enough evidence to support these performance issue claims in modern versions of ColdFusion that perhaps the problem existed "back in the day" and it's since been remedied. So over the weekend I blew the dust off my CFMX7 install, and ran the tests again on a like-for-like config, alongside re-running the tests on CF10. And for the sake of completeness, here are the results (they should be read in conjunction with the original article, as I do not go into great detail as to what was being tested).

    Saturday 3 August 2013

    Saving class files in ColdFusion (and Railo): anecdote should not take precedence over analysis

    There was a thread the other day on the Railo Google Group regarding the "Save Class Files" setting on Railo. I piped up with my usual spiel that I don't think it's a worthwhile setting to use on ColdFusion:
    Yeah, I can't vouch for Railo, but on ColdFusion saving class files rapidly becomes a performance hit on the system (Windows) if your app is such that you generate more than a thousand or so classes. The reason being - it seems - that Windows really struggles to file-scan a directory to find the pre-compiled class if it's needed... say the one in memory has been garbage collected... once there are more than a few hundred files in that directory. On big apps it's more expedient to let the class recompile from source code than rely on Windows finding and loading a saved one.

    I doubt this is a problem on *nix-based file systems.

    The issue with CF is that all the classes are stored in one flat directory. If they were stored hierarchically (which shouldn't be too much of an issue?), then there'd be no problem. I did mention this to the Adobe bods, but they looked at me like I was speaking [some language they didn't understand... CF perhaps], and that was that.

    Anyway... I dunno if the same consideration exists on Railo, but this would be one reason why one might not want those class files saving. Something to test, perhaps.
    Mark Drew subsequently suggested it might be a topic for a blog article, so here one is.

    Sunday 28 July 2013

    OK, I'm very confused: arraySort() with a callback...?

    I'm sitting at Shannon Airport awaiting my return flight to London, and killing time via Guinness and responding to comments on my blog. There are no little old catholic ladies here today to keep me bemused, indeed it's very quiet.

    Anyway, this is the comment I'm currently trying to reply to:

    I executed the example you have showed above for customised sorting using arraysort function, but i didn't get the same result. The output i got was the array that i defined in the code. I can't understand why its not happening for me.
     The code in question is this:

    a = [
        {firstName="Witi", lastName="Ihimaera"},
        {firstName="Patricia", lastName="Grace"},
        {firstName="Alan", lastName="Duff"},
        {firstName="Lee", lastName="Tamahori"},    // OK: not an author
        {firstName="Keri", lastName="Hulme"}
        function (e1, e2){
            return compare(e1.lastName, e2.lastName) > 0;

    Tuesday 9 July 2013

    Well done Adobe ColdFusion Team

    Hopefully you've heard there's a patch out for ColdFusion 10 (now version 10.0.11) for the web sockets security hole that Henry Ho noticed a week or so ago. I did some investigation on the issue, and identified four separate problems with the web sockets implementation on un-patched (10.0.10 and below) ColdFusion 10 installations.

    The good news is that two of those four issues are fixed, and they are the two significant ones:
    • public CFC methods were callable via web sockets. Only remote methods ought to be externally accessible;
    • non-web-accessible CFCs were accessible via web socket requests, provided there was a ColdFusion mapping to them.
    I've verified those are now fixed.

    Monday 8 July 2013

    Quick note: CFLib now accepting ColdFusion-10-specific UDFs

    This should possibly have happened a while back, but I suspect no-one's mentioned it until recently, so nothing was done about it.

    When one submits a UDF to CFLib, one needs to specify which ColdFusion version it is for. It was possibly a bit of an oversight that until now "ColdFusion 10" was not on the selection list. It is now, and CFLib has had it's first submission (and approval) of a ColdFusion-10-specific UDF, from James Moberg: isImageCMYK().

    There's a bunch of interesting stuff ColdFusion 10 can do with function-expressions, callbacks and closures, so perhaps you have a treasure trove of ColdFusion 10 stuff sitting on your hard drive that the community could benefit from? If so, please consider submitting it to CFLib. Cheers.

    I'll have a poke around and see if I do. Although I've not done anything "production ready" on ColdFusion 10 yet.


    Saturday 6 July 2013

    CFML: REST requests don't seem to correctly use Application.cfc either

    The emphasis in the title is an allusion to web socket requests also not respecting them.

    God knows what this article will read like. I headed to the pub to catch the last quarter of the Aussie v Lions match, and I've been sitting here since. I'm over in Portumna visiting my son, and other than my 4h appointment doing that, I've kinda got nothing better to do here, so I'm still in the pub (which has wireless), amusing myself and drinking Guinness. Am just finishing my third pint. And will order a fourth. It's 3pm ;-)

    Anyway, someone posted a question on Stack Overflow about how erroring REST requests don't fire onError() calls. This is a known issue: 3506757. But it was enough for me to furrow my brow and decide to have a look into it.

    Now I'm no REST expert (neither in the context of ColdFusion, nor in general), so it always takes me a bit to get a REST CFC / function working, but I've come up with this test environment:

    // Application.cfc
    component {
       = "testappCfcIssue09";
        public void function onApplicationStart(){
            restInitApplication(expandPath("../api"), "api");
        public void function onError(){
            writeLog(, text="#GetFunctionCalledName()# called");

    This is a fairly vanilla Application.cfc. The onApplicationStart() stuff is just to work around some lazy programming on the part of Adobe, in that when one changes a REST-aware CFC, it will error until one restarts the REST engine. The onError() is just there in case REST calls call this onError() instead of the one in the directory the REST CFCs are in (I came into this not knowing how this stuff was handled at all, so just making sure).

    <!--- testException.cfm --->
    <cfhttp method="get" url="http://#CGI.http_host#/rest/api/Messaging/forceError" result="response">
    <cfdump var="#response#" label="HTTP Response">

    [I have decided against Guinness for the fourth: it's cider. It's a cracking hot day here today in Portumna, so not really Guinness weather]

    This calls my REST method, and dumps the response. Now, over in the API dir, I have this lot:

    component rest=true {
        remote string function gday(required string name restargsource="query") httpmethod="get"  {
            return "G'day #name#";
        remote string function forceError() httpmethod="get" restpath="forceError"  {
            throw(type="ForcedException", message="Exception forced", detail="Because you asked me to");

    The first method is just me testing that stuff was actually working properly with a vanilla method. The second method is one that forces an error, specifically so I can see what happens when an exception occurs.

    And I have this Application.cfc in this directory as well, to log everything which goes on during REST requests:

    // Application.cfc
    component {
                   = "restRequestLogging02";
        this.sessionManagement    = true;
        public void function onApplicationStart(){
            writeLog(, text="#getFunctionCalledName()# called");
        public void function onApplicationEnd(){
            writeLog(, text="#getFunctionCalledName()# called");
        public void function onSessionStart(){
            writeLog(, text="#getFunctionCalledName()# called");
        public void function onSessionEnd(){
            writeLog(, text="#getFunctionCalledName()# called");
        public void function onRequestStart(){
            writeLog(, text="#getFunctionCalledName()# called");
        public void function onRequestEnd(){
            writeLog(, text="#getFunctionCalledName()# called");
        public void function onRequest(){
            writeLog(, text="#getFunctionCalledName()# called");
            include arguments[1];
        public any function onCfcRequest(required string cfc, required string method, required struct args){
            writeLog(, text="#getFunctionCalledName()# called");
            var o = createObject(arguments.cfc);
            var metadata = getMetadata(o[method]); 
            if (structKeyExists(metadata, "access") && metadata.access == "remote"){
                return invoke(o, method, args);
                throw(type="InvalidMethodException", message="Invalid method called", detail="The method #method# does not exists or is inaccessible remotely");
        public void function onError(){
            writeLog(, text="#getFunctionCalledName()# called");
        public void function onMissingTemplate(){
            writeLog(, text="#getFunctionCalledName()# called");

    The only non-obvious method in this is the onCfcRequest() one. The code here is reflective of the unexpected "security issue" onCfcRequest() could effect in an application that I blogged about a while ago. Any onCfcRequest() method should do this lot as a minimum. That consideration aside, basically every event handler call is logged. That's the crux of things.

    Thursday 4 July 2013

    Response to comment (since redacted, it would seem) posted on the Adobe ColdFusion Blog

    I headed over to the Adobe ColdFusion Blog where there's an article on these security holes in ColdFusion (via web sockets) to reply to an update Awdhesh made yesterday. But the comment is gone. Well no it's not, here it is:

    Sunday 30 June 2013

    Web socket security issue: risk assessment & findings

    Yesterday I engaged in some unrepentant shock tactics, writing an article entitled "Security warning: stop using ColdFusion web sockets right now". This warning arose from my initial investigations into an apparent significant security hole in web sockets, as reported by Henry Ho on Stack Overflow. I have checked into things more thoroughly, and here's the details of my findings.

    Firstly, I have considered how responsible I am being by publishing this material. But I have concluded my readership is far less than Stack Overflow's, so the vulnerability is already public. Plus I think it would be helpful for people to know what they're up against. Plus - unabashedly - I hope the "publicity" will encourage Adobe to deal with this ASAP.

    Threat summary

    OK, so what's the story? Basically ColdFusion 10's web sockets have a couple of significant security failings, and some other unhelpful quirky behaviour as well.

    Thursday 20 June 2013

    Is ColdFusion's REST implementation more verbose than it needs to be?

    I've been using some REST web services at work recently (CFML calling .NET ones; I'm just working on the CFML side of things, unfortunately), and also pottering around with ColdFusion 10's REST stuff at home occasionally. And then I wrote my "things I ain't researching" article, and one of the entries in that was to look more at CF's REST implementation more thoroughly, as well as Taffy and Relaxation. That in turn reminded me of a thread on Twitter in which Sean was denigrating ColdFusion 10's approach to REST, instead espousing a by-convention approach to things, or just in general not having the REST config alongside the code itself. I don't necessarily agree with him on the latter (I don't necessarily disagree, either!), but it's thought-provoking.

    One thing that persisted in my mind is that it seems like there's a lot of horsing about making a method REST-callable, and after discussing a conventions-based approach with both Sean and separately with Adam Tuttle, I turned my mind to that.

    God my writing is awful today, sorry. Slightly hungover. Bear with me.

    OK, so here's a CFC and a method:

    component {
        public string function greet(required string name) {
            return "G'day!";

    The minimum I seem to be able to get away with to "RESTify" this is:

    component rest=true {
        remote string function greet(required string name restargsource="query") httpmethod="get" {
            return "G'day!";

    Friday 14 June 2013

    Follow-up to "212 untriaged ColdFusion 10 bugs"

    I found myself discussing the mountain of untriaged ColdFusion 10 bugs again just now, and thought I might check out if any progress has been made on them. The good news is that the list is down from 212 to 183. At least it's moving in the right direction.

    I lost the code I used to generate the bug table for the earlier article, so I've knocked it together again, and this time saved it as a gist:

    I've also chucked it up on CFMLDeveloper. I'll augment it at some stage to accept different CF versions, etc. Or someone could update the Gist and let me know and I'll chuck the updated version up there.

    This is not exactly the finest code in the world, but it's handy. I stated working on a bug-update-notifier thing ages ago, but never finished it. I should crack on with it, I guess.

    Anyway, my lunch needs eating, so I'm off.


    Tuesday 28 May 2013

    CFML: Application.cfc look-ups and linked directories

    This is a pretty non-descript topic / article, sorry. Someone raised a question on the Adobe ColdFusion forums about the possibility of CF10 not getting along well with Application.cfc look-ups from within a symlinked directory. I doubted this would be an issue, but I wasn't 100% sure so I thought I'd check it out.

    Links / junctions
    Before I start, just in case you're unsure about symlinks, here's what Wikipedia has to say about them. These are pretty prevalent on *nix systems, but they're under-utilised on Windows. Mostly because people are unaware they exist. Windows has actually been able to effect pretty much the same thing as a symbolic link since Windows 2000. Well: the Windows GUI shell couldn't, but the underlying NTFS file system has supported junction points since Windows 2000 came out. And a junction point amounts to the same thing.

    Junction points are bloody handy. I have quite a number of CFML app servers running on this machine: CF5, CFMX7, CF8, CF9 (multiple instances), CF10 (multiple instances... Railo Express, some manner of OpenBD install (gathering dust)... and they all have their own discrete webroots for platform-specific stuff (eg: C:\webroots\cf5, C:\webroots\railo-express, etc). However I have a repository of all my common code @ C:\webroots\shared. Into each of my version-specific webroots I junction-in a reference to shared, so I have C:\webroot\cf10\shared etc. As far as CF10 is concerned, C:\webroot\cf10\shared is a discrete directory. And as far as Railo is concerned, C:\webroots\railo-express\shared is a discrete directory. But it's all the same place. Cool. I dunno how to create these things on *nix (something to do with ln comment), but , but on Windows it's just this:

    C:\webroots\cf10> mklink /d shared c:\webroots\shared

    Where obviously "shared" is what the junction ends up being called, and c:\webroots\shared is where it points to.

    I've never had any problems with these on ColdFusion or Railo, and have been using them for a decade.

    Anyway, that was a digression. Another side issue that came up from the original question is how does CF look for which Application.cfc (or .cfm in the case of the original question) to execute, for a given request. I'd forgotten that there were multiple "modes" for doing this settable in CFAdmin, and had never really paid much attention to them, so decided to roll both these concepts / questions into one investigation.

    Firstly, lets look at the options on offer in CFAdmin:

    As various people have blogged, docs on this setting are a bit thin on the ground, so I can reproduce it in its entirety without blowing out my word count:

    Select the order in which ColdFusion searches for Application.cfm or Application.cfc if it is not found in the current project folder. You can set ColdFusion to search as follows:

    • default search order: ColdFusion looks for an Application.cfc/Application.cfm file from the current folder until the system root directory. On Windows, this could be C:\ and on UNIX, /opt.
    • till web root: ColdFusion looks for an Application.cfc/Application.cfm file from the current folder till web root.
    • in web root: ColdFusion looks for an Application.cfc/Application.cfm file in the current folder or web root.
    And that's all there is to it. I think perhaps the guidance is wrong for *nix... surely / is the root, not /opt? I suppose it depends on permissions, but the same could be said for the /opt dir as well. And "till"? Sigh. But anyway. There's also another significant terminology error in there, but I'll get to that.

    To demonstrate each of these, I have set up the following directory structure on my box:


    There are several significant elements to this:
    • The root
    • The ColdFusion instance directory
    • The ColdFusion app root - CF serves files from within here
    • The web root - the web server serves files from within here
    • A junction
    • The directory that is junctioned
    • Test files
    In the table below, I highlight where ColdFusion will look for an Application.cfc or Application.cfm (it'll be one or the other, in that order of precedence, btw), given the specified file being requested.

    Tuesday 23 April 2013

    ColdFusion REST: is this a bug (in either CF or just my understanding)?

    (And, no, this is not a case of Betteridge's Law... I'm actually asking a question 'cos I don't know the answer).

    I was having a mess around REST stuff this afternoon, half-heartedly trying to work out what the question actually was that someone asked on Twitter, and came across some puzzling behaviour. I don't really know REST from Adam (as it were) so this is definitely a question, not a statement.

    Tuesday 2 April 2013

    ColdFusion bugs I'd like to see dealt with: param (first in what will be a series)

    With the upcoming ColdFusion 11 pre-release, I'm going to start banging about some ColdFusion bugs that piss me off. I'll mention them as I encounter them in my day-to-day work.

    First up: param. There's a bug with param detailed in bug 3364510. Basically it's not been completed.