Tartan - Getting it running on BlueDragon

May 27, 2005 · 9 Comments

I spent several hours over the last couple of nights trying to get Tartan running on BlueDragon 6.2. I found several bugs in BlueDragon in the process. The first stumbling block is that BlueDragon does not support WEB-INF.cftags.component as the universal base class for all components. It's mentioned several times in the CFMX documentation so this is at best a compatibility issue that New Atlanta should document and at worst a bug they should fix. Workaround: change WEB-INF.cftags.component to any. The second stumbling block I hit was that the pseudo-constructor of a derived CFC could not access variables set in the pseudo-constructor of the base CFC. New Atlanta just released a Hot Fix that fixes this bug. You'll need it to get Tartan running. Then I tripped over <cfbreak/>. BlueDragon thinks that's an illegal tag. Add a space and it's happy: <cfbreak />. I found the same problem with <cfrethrow/>. Changing it to <cfrethrow /> made BlueDragon happy. Finally, BlueDragon does not allow derived CFCs to call private methods in the base CFC via super. Since private methods are accessible to derived CFCs (because CFML's private really means protected), this should definitely be valid. Workaround: change ServiceFactory.getServiceArgs() to be access="public". At this point my sample application (for my frameworks talk) runs on BlueDragon in all seven variants. Oh, and this exercise did highlight a bug in my code! My Tartan configuration file did not have a <parameters> tag around my DAO factory parameters which caused them to be ignored. This meant that my queries were being run with username="" password="". On CFMX, blank credentials are ignored and the values in the data source (in the CF Admin) are used. On BlueDragon, the blank credentials are used (so the queries failed).

View count: 725

Tags: bluedragon · coldfusion · tartan

9 responses so far ↓

1 Paul Kenney // May 27, 2005 at 10:51 PM

Wow Sean, thanks. I don't know what to say except that some of these issues are rather serious incompatibilty issues when dealing with CFCs. I find it amazing that these incompatibilities still even exist in the latest version of BD. Perhaps compatibilty just isn't really important when dealing with CFCs. Too bad.
2 Alan // May 28, 2005 at 12:29 AM

We take compatability very seriously, and if you haven't filed these bugs Sean, then we'll make sure they are logged. That said, i find it interesting to see how CFMX has broken another basic OO fundamental yet the community is very happy to turn a blind eye.

If the underlying object has a method marked as 'private' then private is what it should be. That is the whole point of it being marked 'private'. The OO world recognizing the need for greater access, introduced 'protected' to provide the control you require. Yet CFMX decides not to implement this and redefine what 'private' means.

My biggest issue with CFC's is CFMX poor implementation of the 'var' variable. If you define a variable inside a CFFUNCTION it should always be scoped to that execution thread, and not the class. Most other languages operate like this; but again we see CFMX redefining this area of programming. One can only assume the 'var' was a hack to get around a bug, since they already had the 'this' scope properly defined to access CFC scope variables.
3 Paul Kenney // May 28, 2005 at 1:03 AM

The way I see things, for something to be considered compatible it must exhibit the same behavior as the object of its compatibity. This means that even though CFMX might not behave the way you think it *should*, it nonetheless does have specific and documented behavior that cannot be ignored when making claims of compatibility. Additionally, much of this behavior has been around since CF 6.0 in mid to late 2002. Any issues with the super scope have been around since it was introduced in August 2003. It is nice to want to do it "right", but in this case the correct (and perhaps best) thing is to make it work the way it is expected to work.
4 Vince Bonfanti // May 28, 2005 at 9:37 AM

Sean: thanks for putting in the effort to track down and document these issues.

Paul: the situation may not be as bad as it appears at first blush.

Regarding "WEB-INF.cftags.component", it's possible to configure the location of "component.cfc" in BD, so it should be possible to configure BD to recognize "WEB-INF.cftags.component", possibly in conjunction with a mapping for "/WEB-INF". The instructions will vary based on which BD edition is being used. We could probably modify BD to recognize "WEB-INF.cftags.component" as referencing "component.cfc" even though that's not really where the file physically resides. We'll open a bug report on this.

(In my opinion, the real issue here is that the location "WEB-INF.cftags.component" is implementation-dependent, and what's really needed is an implementation-independent way to specify TYPE="component" or RETURNTYPE="component" to indicate a generic component type. For example, what if a future version of CFMX moves the location of "component.cfc"? It would break your code--that's what I mean by implementation-dependent.)

Regarding <cfbreak/> and <cfrethrow/>, these are apparently manifestations of the same bug in BD. Note that if you simply use <cfbreak> and <cfrethrow> (which is what most people will do anyway), then the code works properly.

Regarding access to inherited "private" methods via "super", this is apparently a bug in BD due to our mis-interpreation of what "private" means in CFML (silly of us to think that "private" means the same thing in CFML as it does in every other object-oriented programming language). We'll open a bug report on this.

You can expect to see all of these issues fixed in the BlueDragon 6.2.1 updater planned for release later this summer.
5 Sean Corfield // May 28, 2005 at 11:55 AM

Vince's reaction seems much more reasonable than Alan's - this is about compatibility not "rightness".

access="private" has worked the same way for three years and is very well documented. I think most people agree it's confusing when compared to C#, Java or C++ but that's just the way it is. "this" is also a bit confusing compared to those languages too. Much has been written about both of these topics over the last three years...
6 Paul Kenney // May 28, 2005 at 2:53 PM

Thank you Vince for responding to these very practical issues. I appreciate it. I imagine that some of these issues are also what keeps cfcUnit from working on BD as well, although I haven't really looked into it myself.
7 Sean Corfield // May 28, 2005 at 4:42 PM

cfcUnit uses the (unsupported) ServiceFactory class which BlueDragon does not provide. That's the main reason why cfcUnit will not run on BlueDragon.
8 Paul Kenney // May 28, 2005 at 5:00 PM

Well shoot, I forgot about that one. Thanks.
9 Vince Bonfanti // Oct 19, 2005 at 7:43 AM

FYI, for anyone who's interested, these issues have all been fixed in BD 6.2.1 and Sean's CFUNITED examples all run without modification. The public beta of BD 6.2.1 is planned for release next week.

An Architect's View

CFML, Clojure, Software Design, Frameworks and more...