OpenBlueDragon Compatibility with Coldbox 3 [Patches]

I took some time today to coerce ColdBox 3.0.0 RC1 into running on
OpenBlueDragon 1.4 and thought I'd share my changes and thoughts with
both lists, So far the basic handlers and controllers work (ie, I can
display the demo page, cache information, debugger, etc. but haven't
gone much further than that)

Here's what I changed:

1. In what I believe to be an OBD Bug, negative numbers are not
supported as cases in switch statements unless they are quoted (Which
I imagine has a performance penalty), So in the file "coldbox/system/
logging/LogLevels.cfc" the -1's must be quoted on lines 31 and 56, I
have submitted this as a bug to the OpenBlueDragon tracker

2. The CFMLEngine.getVersion() function returns "1" for OpenBlueDragon
due to a change in the version number scheme, This breaks a few
things, so coldbox/system/core/cf/CFMLEngine.cfc needs to be updated,
I added a test to see if (version=1 && engine=bluedragon) then
version=7, to make it equivalent to all the checks that test for what
I assume is NewAtlanta's BlueDragon/JX, which OBD is obviously very
compatible with, I'm not sure if there are any other features that can
be enabled as OBD has been under active development for a while now,
and is probably a fair bit further along than BD/JX was when these
checks were written.

3. This next one is nasty, Once CFML7 support is enabled, CB3 starts
to make use of cfinterface in it's caching interface, The
OpenBlueDragon cfinterface syntax is entirely different from what's
expected in several ways (Full details here, First they
actually have no cfinterface tag, instead they have an attribute to
cfcomponent, type="interface", And also interfaces cannot "implement"
other interfaces, instead they become type="abstract" components which
can be implemented by others. I patched the relevant files to change
them to the OBD syntax but obviously that makes them incompatible with
Adobe and Railo.

I'm not sure how high a priority fixing this is for the OBD team, I'll
take a stab at it in a month or so if they don't move on it, request
submitted to their tracker here:,
The only other way I can think of would be to have special files set
aside for OBD that duplicate the functionality of pretty much
everything in coldbox/system/cache/ with a very slightly different
syntax, which is kind of absurd.

4. There are a few other bugs I encountered while pressing onward,
including at least two that break forgebox, the first is an OBD
compatibility issue, their cfzip tag uses a zipfile attribute, instead
of just file (compatibility fix requested here:, and
second there's something broken in coldbox/system/core/conversion/
JSON.cfc that will surely effect other projects/modules, I think it's
getting structs & queries confused when doing a conversion, but I will
need more time to track that down (And May be able to replace it with
native functions for OBD). Finally I believe the coldbox cache reap
method may not be threading properly, and will dig into that if time

Inlined below are the changes I made in patch format (So they're
available in the list archives), on any unix-like platform you should
be able to apply them by entering the coldbox directory, and running
"patch -p0 < /path/to/patch",

I'll also host them as long as it's convenient:

Sorry that this email is HUGE, Just wanted to make sure I put
everything relevant in.

- Josh

diff -Naur ./system/core/cf/CFMLEngine.cfc ../nPatch/system/core/cf/
--- ./system/core/cf/CFMLEngine.cfc 2010-11-26 01:31:04.132195089
+++ ../nPatch/system/core/cf/CFMLEngine.cfc 2010-11-26
00:55:09.562431258 -0500
@@ -55,6 +55,10 @@

   <!--- Get the current CFML Version --->
   <cffunction name="getVersion" access="public" returntype="numeric"
hint="Returns the current running CFML version" output="false" >
+ <cfif getEngine() eq "BLUEDRAGON" and
( listfirst(server.coldfusion.productversion) eq "1" ) >
+ <!--- OpenBlueDragon restarted their version numbers at 1.x, But
they are at least CFML7 compatible --->
+ <cfreturn 7 />
+ </cfif>
     <cfreturn listfirst(server.coldfusion.productversion)>

@@ -182,4 +186,4 @@
     <cfreturn instance[arguments.engine][arguments.feature]>

\ No newline at end of file

diff -Naur ./system/logging/LogLevels.cfc ../nPatch/system/logging/
--- ./system/logging/LogLevels.cfc 2010-11-26 01:31:04.143188308 -0500
+++ ../nPatch/system/logging/LogLevels.cfc 2010-11-26
00:55:09.902389729 -0500
@@ -28,7 +28,7 @@

   function lookup(level){
- case -1: return "OFF";
+ case "-1": return "OFF";
       case 0: return "FATAL";
       case 1: return "ERROR";
       case 2: return "WARN";
@@ -53,7 +53,7 @@

   function lookupCF(level){
- case -1: return "OFF";
+ case "-1": return "OFF";
       case 0: return "Fatal";
       case 1: return "Error";
       case 2: return "Warning";
@@ -68,4 +68,4 @@

\ No newline at end of file

diff -Naur ./system/cache/ICacheProvider.cfc ../nPatch/system/cache/
--- ./system/cache/ICacheProvider.cfc 2010-11-26 01:31:04.131236435
+++ ../nPatch/system/cache/ICacheProvider.cfc 2010-11-26
00:55:09.556432075 -0500
@@ -13,7 +13,7 @@
   Please note that all cache providers have a reference back to the
CacheBox Factory.


I can see some of these changes going into the core for compatibility, but if their cfinterface is not supported, then that is very hard to change as I do not want to keep different copies for each engine.

Maybe forking coldbox into an Open BD version would be ideal and then just merging patches into it, but it is very hard when Adobe + Railo is extremely compatible.

So, maybe we can wait on the fixes from the open bd team for the obvious and then discuss if some of these changes are worth it.

Luis F. Majano
Ortus Solutions, Corp

ColdBox Platform:
Linked In:
IECFUG Manager:

Oh right, also

Finally I believe the coldbox cache reap
method may not be threading properly, and will dig into that if time

It looks like it's an issue with the difference between which
variables are passed into the thread scope, OpenBD doesn't pass the
variables scope from a parent cfc by default, but DOES pass a "this"
scope which can be used instead (
index.php/CFTHREAD#Notes, Second and third paragraph)

As a simple patch I just added an engine check, and under BlueDragon
use a cfthread that uses the "this" scope, and leave the Adobe one to
keep using "variables", I'm not sure this is the most elegant solution
but as far as I can tell this solution is working, I admit however I
don't really understand how the reaping process works well enough to
be confident that I have not introduced any other bugs, All I know is
that the cache is being reaped (The "time since last reaped" is
updating, and old/expired objects do get removed)

Patch hosted at
and inlined below:

--- ../patched/system/cache/providers/CacheBoxProvider.cfc 2010-11-08
10:52:28.000000000 -0500
+++ ./system/cache/providers/CacheBoxProvider.cfc 2010-11-26
03:19:07.252259501 -0500
@@ -555,11 +555,11 @@

       <!--- check if in thread already --->
       <cfif NOT instance.utility.inThread()>

The bug regarding negative numbers in switch/case statements has now
been fixed in the OBD nightly build,
So one of my patches (
bugfix.patch) is no longer needed

- Josh