Such was the case when I was working with a coworker recently on getting data back from some Oracle stored procedures into either Open BlueDragon or Railo. Before I proceed, let me state very clearly that I hardly ever touch Oracle so if I'm off-base on any of this I'm happy for an Oracle expert to educate me. In my defense, I will say I did quite a bit of searching on this topic, and more hours of experimentation than I care to admit, so I wasn't just screaming "Oracle sucks!" and not actually trying to intelligently and logically get things to work. Also bear in mind that in this situation we didn't write the storedprocs and we do not have the ability to alter them. (Necessity is the mother of invention and all that.)

Back to the task at hand. The storedprocs in question return Oracle REF CURSORs, which is basically Oracle's way of thumbing their ever-expanding nose at the world by doing things differently than everyone else simply because they want to. (Oracle fans, if there's a legitimate explanation for this utter nonsense I'm all ears, because I certainly couldn't find one.)

If your first thought is, "But this just works on Adobe ColdFusion!" you are in fact correct. This is because Adobe CF ships with DataDirect drivers that handle getting an Oracle REF CURSOR into a format that can be used by CF. Because REF CURSORs ain't your plain old Java ResultSets like the entire rest of the known database universe uses, my assumption is that there's some translation that goes on either in the driver, or on the CF side, or both, to make this work. But in other CFML engines if you're using the plain old JDBC drivers--yes, even Oracle's own JDBC drivers--this doesn't "just work."

Let's assume it's entirely in the driver. I could either purchase the DataDirect drivers (expensive, and silly to have to do this for this one seemingly small thing), or I could use the ones that ship with CF. Well, a little birdie told me (ahem) that if you try to use the ones that ship with CF anywhere but with CF you'll get a licensing error when trying to run queries. So that solution's out.

You might also think you could simply call the storedproc from within a normal CFQUERY tag as opposed to using CFSTOREDPROC and an out parameter. Good thought, but even if you get the syntax figured out, since the storedprocs in question are looking for an out parameter to be passed into the storedproc (figure that one out), there's no real way to get the data returned from the storedproc into a variable within the SQL statement that you can actually access. I spent a lot of time on this and got the storedproc itself executing fine, but getting at the data was where I spent the bulk of my experimentation time, and I finally gave up.

So where does that leave us? Long and short of it is that without using the DataDirect drivers (even if that would in fact work), there is no way that I could come up with that would allow calling an Oracle storedproc that returns a REF CURSOR from OpenBD or Railo that would work.

At that point do we throw up our hands in despair and state that it simply isn't possible? Certainly not! We expand our thought process, put all options on the table, and forge ahead because we must not let technology, particularly of the Oracle variety, defeat us!

Since I was at the point where there was no way to have OpenBD or Railo deal with what the Oracle storedproc was returning (and believe me I'm happy to be proven wrong here), I decided the most expedient route would be to write the database access piece in Java and have CFML call that Java object. Once I'm in Java I can work with the Oracle and JDBC datatypes directly and have more control over what I will return to the CFML engine once I get the REF CURSOR back from Oracle.

The question then becomes if it's better to convert the REF CURSOR into a native CFML query object on the Java side, or to return something like a standard Java ResultSet to CFML and use the ResultSet directly. There are numerous other options as well, particularly once we're dealing with this in Java and have the freedom to do pretty much whatever we want.

I won't go into the gory details, but in one of my early attempts I ran into a problem where I couldn't access the ResultSet because by the time the Oracle delegate class was delegated to the Tomcat delegate class, I had to hack around a bit and get the underlying delegate on the Oracle side just to display the data. Neat problem to solve, but not exactly the most straight-forward solution.

I then decided to try creating a query object native to the CFML engine from the Java ResultSet. This worked well, and is certainly a valid approach, particularly if you know you're going to deploy to a specific CFML engine. If you want to build something that will work on any CFML engine things get more complicated because your Java methods have to return a specific datatype, so you can't have a single method in your Java class that will return the various underlying CFML query object types to the respective engines.

But as a wise man once said, all problems in computer science can be solved by another level of indirection (except, of course, the problem of too many levels of indirection). So I created the Java class to talk to Oracle and return the REF CURSOR, and then wrapped that puppy in a CFC that has conditional logic to return a CFML query object native to the engine on which it's running (i.e. either OpenBD or Railo). Works great!

The only outstanding issue at this point that makes me a hair uncomfortable is that in order for all this to work, I can't explicitly close my callable statements, ResultSets, and datasource connections on the Java side. If I close those items in Java and then return the ResultSet to the CFML engine, then I can't actually iterate over the ResultSet since it's closed.

I could of course close the ResultSet from CFML (I wouldn't have access to the callable statement or the database connection directly), but I'm not nearly as concerned about the ResultSet as I am about the database connection. At least I'm using the Tomcat datasource connection pooling so that should mitigate this concern a bit. In theory Tomcat and the JVM will handle closing this stuff when it's no longer in use, but I need to do a bit of load testing to be sure it's going to work well under load.

There's also some attributes in the Tomcat <Resource> XML definition that you can leverage to alleviate potential problems. Specificaly the maxActive, maxIdle, removeAbandoned, and removeAbandonedTimeout attributes can help keep things cleaned up since I'm in situation where I can't clean things up manually.

As far as the database connection pooling goes, thus far we've seen problems on Windows with Tomcat 6.0.26. It works for a while but then starts throwing database connection pooling errors and all the connections time out. Drop this all on Red Hat Enterprise Linux with Tomcat 7, and things are rock solid. Go figure.

I'm happy to share the Java and CFC code if anyone's interested, and I'm really curious to hear how others have solved this issue because I'm still not convinced what I came up with is the best solution, even though it's certainly working well. So far, anyway (knock on wood).

Contact Loren Scherbak (contact info below) if interested.

========================================
Job Link on USAJOBS: http://cot.ag/h7MFf1

The Archives of American Art at the Smithsonian Institution is offering a rare, Federal Grade 11 programming position. We are a Coldfusion 9 shop with a lot of creative opportunities to work with XML. We only have one dedicated programmer position, but this position gets to work with a great team comprising a web/usability specialist, a metadata specialist, and a database administrator. The Archives is in the forefront of the archival community in using library catalog data (MARC) and Encoded Archival Description (EAD XML) to describe fully digitized collections on our website.

I can talk with anyone at great length about our work, but I want to get this announcement out to as many people as possible as we have a very short window for the job opening. The application is due by Dec. 3rd.

Loren Scherbak
Archives of American Art
Smithsonian Institution
202-633-7968
scherbakl@si.edu

Note that if you're setting up an Ubuntu server, the server-related stuff that follows (Apache, Tomcat, and MySQL) will be pretty much the same on a server as it is on a dev machine with a couple of differences. First, you'll want to have Tomcat autostart at boot on a server (which I don't do on my dev machine). Second, and this is a matter of personal preference, I tend to put Tomcat in my home directory on my dev box, but in /opt on the server.

So open up a terminal and let's the the easy apt-get stuff out of the way first.

INSTALL APACHE

sudo apt-get install apache2

INSTALL MYSQL

sudo apt-get install mysql-server mysql-client
 

INSTALL VIM & EMACS

sudo apt-get install vim emacs

You can also install Java and Tomcat via apt-get, but I prefer to download these items directly from their respective sources. We'll start with Java.

DOWNLOAD/INSTALL JAVA

1. Open a browser and go to http://java.sun.com (sorry Oracle, I'm not using your URL until you turn this one off!)
2. Mouse over "Downloads" and click on "Java for Developers"
3. Scroll down a bit on the next page and click on the "Download JDK" button (you'll want the full JDK, not just the JRE)
4. On the next page, click on the Platform button and choose either "Linux" (32-bit) or "Linux x64" (64-bit) as appropriate for your machine. Then scroll down and hit the "Continue" button.
   
5. Under "Available Files" on the next page, click on the .bin file, not the .rpm.bin file.
6. After the download completes (and I'm assuming you downloaded to your Downloads directory), open a terminal and do the following, hitting enter after every line (note the file name may be different based on the version you download):
   cd ~/Downloads
   chmod +x jdk-6u22-linux-i586.bin
   ./jdk-6u22-linux-i586.bin
7. You'll see all the files extract, and you'll wind up with a jdk1.6.0_22 directory (or perhaps something different based on the version you downloaded). Personally I like to have Java in my /opt directory, so if you want to follow suit, type the following in your terminal (again hitting enter after each line):
   sudo mkdir /opt/java
   sudo mv jdk1.6.0_22 /opt/java

With .bashrc open, scroll down to below the HISTSIZE and HISTFILESIZE lines (at least that's where I put this stuff), and you're going to add the following lines:

PATH=${PATH}:/opt/java/jdk1.6.0_22/bin
 export PATH
JAVA_HOME=/opt/java/jdk1.6.0_22
export JAVA_HOME

Save the file, and then you'll have to log out of your terminal and log back in for these settings to take effect. Type exit and then hit enter to close your terminal, and then re-open the terminal. To make sure your settings took, type the following in your terminal, hitting enter after each line:

echo $PATH
echo $JAVA_HOME

You should see the Java directory included in your path, as well as see it for the value of JAVA_HOME.

Note that by editing .bashrc the changes only affect your user. If you want these settings available to all users, you'll be editing /etc/profile instead.

DOWNLOAD/INSTALL TOMCAT

With Java in place, let's grab Tomcat. You can of course substitute a different JEE server or servlet container if you're so inclined, but if you do you're on your own for the setup. ;-)

1. Go to http://tomcat.apache.org in your browser.
2. On the left-hand side under "Download" click on the latest version, which is currently Tomcat 7. (Note that Tomcat 7 is still technically in beta if you care about such things.)
3. On the download page, scroll down a bit and under "Core" click on the .tar.gz link.
4. After the file downloads (again assuming you have downloads go to your Downloads directory), in your terminal do the following (hit enter after each line):
   cd ~/Downloads
   tar -xvf apache-tomcat-7.0.2.tar.gz
5. You'll see the files extract, and at the end of that process you'll have an apache-tomcat-7.0.2 directory in your Downloads directory. I prefer to have that in my home directory on my dev boxes, so type this in your terminal and hit enter (assuming you're still in your Downloads directory):
   mv apache-tomcat-7.0.2 ../
6. Next to make Tomcat a bit easer to access, we'll add a symlink called tomcat that points to the real Tomcat directory. More terminal stuff:
   cd ../
   ln -s apache-tomcat-7.0.2 tomcat

CONFIGURE TOMCAT

Next we need to configure Tomcat a bit, so in your favorite text editor, create a setenv.sh file in Tomcat's bin directory. If you want to do this in your terminal with vi, type the following:

cd ~/tomcat/bin
vi setenv.sh

What we'll be adding to this file is some settings that Tomcat will use when it starts up. Depending on your machine and/or preferences you may want to adjust the memory settings, but if you aren't sure what this stuff does, these are decent generic settings and you can always change them later.

Add these two lines to setenv.sh and then save the file:

export JAVA_HOME=/opt/java/jdk1.6.0_22
export CATALINA_OPTS="-Xms512m -Xmx1024m -XX:MaxPermSize=384m"

Again if you know what you're doing here, feel free to change your memory settings accordingly.

You should now be able to fire up Tomcat without any errors, so navigate to ~/tomcat/bin in your terminal and type ./startup.sh

You'll see a few lines spit out to the terminal, and if you don't see errors, open up a browser and go to http://localhost:8080 If you see the Tomcat welcome screen you're good to go.

Note that I won't be covering additional Tomcat configuration here, particularly hooking it into Apache, because there are a ton of other howtos and blog posts about that very topic. If you have specific questions in this area I'm happy to help, so comment below and I'll either comment or write another blog post as necessary.

ADDITIONAL CONFIGURATION

There's one additional bit of configuration I tend to do because particularly on a dev box, you'll run into a problem with this sooner or later if you abuse your machine like I do.

In a terminal (you and your terminal are friends by now, right?), or using your favorite text editor, you're going to edit /etc/security/limits.conf to increase the maximum number of files your user can have open. Open that file and add the following lines to the bottom of the file:

yourusername soft nofile 10000
yourusername hard nofile 10000

DOWNLOAD AND INSTALL SPRINGSOURCE TOOL SUITE/ECLIPSE

Unless you already have a favorite Java IDE, much as it's not in fashion to say so I'm a big fan of Eclipse. I personally have been using SpringSource Tool Suite (STS) for quite a while now, and it's a great Eclipse-based IDE for Java, Groovy, Grails, and of course CFML development once you throw in CFEclipse.

After downloading the Eclipse or STS of your choice, extract the files and then move them to your home directory (at least that's where I put them). This should be old hat by now--in your terminal do:

 cd ~/Downloads
tar -xvf NAME_OF_FILE_HERE.tar.gz
mv NAME_OF_EXTRACTED_DIRECTORY_HERE ../

STS has a bit of a different directory structure since it comes with tcServer and Roo, so you'll actually go into the directory and be moving the STS directory into your home directory. Since it has a long name like springsource-tool-suite-sts-2.3.2-RELEASE or something like that, I tend to move and rename to something shorter, e.g.:

mv LONG_DIRECTORY_NAME_HERE ~/sts

Once things are moved, you can go into the directory that you moved to your home directory (which will be either sts or eclipse most likely), and then type either ./STS or ./eclipse to launch the program.

ADD LAUNCHER FOR STS/ECLIPSE

Although you can certainly start STS or Eclipse from the terminal if you like, most people tend to like to have a pretty button to click on to launch the program. The bad news is you have to add this yourself. The good news is it's very easy.

1. Right click on the Ubuntu logo in the top left of the screen, and click on "Edit Menus."
2. Click on "Programming," and then click on "New Item" on the right-hand side of the window.
3. Leave the type drop-down set to "Application"
4. For "Name" type whatever you want the name to be (e.g. Eclipse, SpringSource Tool Suite, whatever)
5. For "Command" you need to tell the launcher not only where the executable is, but also where to find Java. So assuming your executable is ~/eclipse/eclipse you'd enter the following in the Command box:
   /home/yourusername/eclipse/eclipse -vm /opt/java/jdk1.6.0_22/bin
6. You can leave the "Comment" box blank, but if you enter something here it's what will show up when you mouse over the icon for the application.
7. Click on the "spring"-looking icon in the left-hand side of the Create Launcher box and you can choose an icon. Note that they're kind of in a weird format. STS comes with its own icon so you can navigate to the STS directory and select the icon.xpm file. If you're using Eclipse you can search for 'eclipse icon launcher ubuntu' on the interwebs and find stuff you can use.
8. Click OK and your launcher will be added to the Programming menu when you click on Applications in the top left of the screen.
   

That's pretty much it! You're now a hard-core Java/CFML developer on GNU/Linux, other than all that pesky Tomcat/Apache configuration of course. As I said earlier if you need help with that, comment below and I'll do my best.

Enjoy!

Thanks to the attendees for participating in what I hope was a useful and informative session. Whether or not you were at BFusion, feel free to email me with any questions you have about anything related to free/open source CFML.

A few quick tips if you find yourself having to access a network drive from Apache and Tomcat on a Windows Server. This is all pretty much old hat but since I still get questions about this fairly regularly and was just setting up some things on some servers this weekend, I figured I'd write this up.

In my situation we're running an application on three VMs behind a load balancer, and users can upload files from the application. Since I didn't want to set up a process behind the scenes that copied uploaded files between all three servers (though it would have given me a chance to take another run at using Unison), we have an uploads directory living on a SAN. This way no matter which VM the user is on, the uploads all go to and are served from a single file system.

On Windows Server, by default services run under the Local System Account, which doesn't have access to network resources. So if you install Apache and Tomcat as services and expect to be able to point them to a UNC path for some of your content, that won't work out of the box. You need to be running Apache and Tomcat under an account that has network access. In most environments in which I've worked this type of account is typically called a "service account," because you'll end up getting a domain account just like your typical Active Directory user account, but of course it won't be associated with a human being.

Once you have that account in place, you go into your services panel, right click on the service, click on "Properties," and then click the "Log On" tab. You'll see by default the Local System Account radio button will be checked. Click the radio button next to "This Account," enter your service account information, click "OK," and then restart the service. At this point your service will be running under the service account and will have access to network resources. Note that you'll have to do this for each service that needs access to the network drive, which in my case meant doing this for both Apache and Tomcat.

That takes care of the web server and things at the Tomcat level in terms of basic access, but you'll likely be configuring an alias of some sort to point to the network drive. In my case I wanted /uploads to point to \\server\sharename\uploads, which meant setting up an alias in Apache, a Context in Tomcat, and a mapping in OpenBD. This is where a lot of people get confused, so I'll go through each of these settings one by one.

The necessity for a web server alias is probably pretty obvious. If you're serving an image directly from your web server, e.g. http://server/uploads/image.gif, if /uploads doesn't exist under your virtual host's docroot, then Apache will throw a 404.

Allowing Apache to access the network drive involves (depending on how you have Apache configured) using a Directory directive to give Apache permission to access the directory, and then an Alias directive so Apache knows where to go when someone requests something under /uploads. So the following goes in your virtual host configuration file:

<Directory "\\server\sharename\uploads">
  Order allow,deny
  Allow from all
</Directory>

Alias /uploads "\\server\sharename\uploads"

You may have other stuff in your Directory directive as well but that's the basics of what will allow Apache to see /uploads as the appropriate location on your SAN.

The next layer down will be your CFML engine. Remember that if in your CFML code you want to read or write files to /uploads, even though Apache knows what that is now, your CFML engine will not. I'm emphasizing that point because it's such a common source of confusion for people. If things are happening in your CFML code, it won't be interacting with Apache at all, so it won't know about the Alias you set up in Apache. Simple enough to solve with a mapping; just go into your CFML engine's admin console and create a mapping that points /uploads to \\server\sharename\uploads and that handles things at the CFML level.

Lastly comes Tomcat. Depending on how you're serving files, you may be proxying from Apache to Tomcat, so if Tomcat needs to know where /uploads lives, since it's not in the webapp's base directory Tomcat will throw a 404 unless you tell it where /uploads is located.

Tomcat doesn't have Aliases in the same way Apache does, but what you can do in Tomcat is configure multiple Contexts under a single host. So in Tomcat's server.xml (or in a separate host config file if you prefer), you simply add a Context that points /uploads to the network location:

<Host name="myapp">
  <Context path="" docBase="C:/location/of/my/app" />
  <Context path="/uploads" docBase="\\server\sharename\uploads" />
</Host>

So now you have things set up in such a way that Apache, your CFML engine, and Tomcat all know where /uploads really lives.

Another point of confusion for people on Windows is the concept of "mapped drive" letters. A lot of people think that if you map \\server\sharename to a drive letter of let's say D:, than in your code you can then access the uploads directory we've been using as our example via D:\uploads.

The simplest way to explain why this doesn't work is to point out that mapped drive letters are associated with a Windows user account. They don't exist at the operating system level. While you may remote into the server using your credentials, map to a network location, and assign that to drive letter D:, another user logging in won't see that mapping, and services running on the server under various user accounts definitely won't know anything about mapped drives.

This is why in all the examples above you see the full UNC path to the network resource being used. You have to use the UNC path in order to get this all to work correctly because that's the only way services running under a service account will be able to address the network resource.

Hope this helps eliminate some of the persistent confusion I see around this issue.

BFusion/BFlex is coming up on September 11 and 12, 2010 in lovely Bloomington, IN. You need to be there, and here's why.

• $30 for one day or $45 for both days is one of the best deals you'll find in the conference world. (No, I'm not missing a zero at the end of those prices!)
• BFusion/BFlex is all hands on, all the time. This isn't a passive event by any stretch. You come armed with your laptop and you get to learn from the best people in the business.
• Multiple all-day classes in both CFML and Flex are available. On the CFML side you can learn Mach-II from the great minds behind it (namely Peter Farrell and Kurt Wiersma), you can learn CFML from scratch from the great Adobe instructor Matt Boles, if you're a programmer already but want to learn CFML you have none other than Simon Free at your disposal, and if you're an open source junkie like me or just want to learn more about the free CFML engines, I'm giving an all-day in-depth class on that.
• Great for all skill levels, from pure beginner up to advanced developers. There's literally something here for everyone so you don't have an excuse not to come. Just check the BFusion and BFlex schedules and tell me you don't see something interesting!
• It's a nice intimate environment where you can corner speakers or other attendees and get whatever help you need.
• Indiana University is a great venue with great facilities. Power and Internet for all!
• Bloomington is a great town with tons to do.

I've been invovled with BFlex/BFusion since the first year and it's one of my favorite conferences. I'm particularly excited this year to be able to help people delve into the open source CFML engines, so I hope to see lots of you there.

Great training, great price, great location, and great people. What are you waiting for? GO REGISTER NOW!

I really regret having to spend the time writing this since in a lot of ways it will be airing dirty laundry. But since Adam is grossly misrepresenting a great deal of what went on during the effort of the CFML Advisory Committee and what led to its eventual demise, I think it's only fair that people don't take Adam's version of the story as gospel. It's far from it.

Preamble

First, I'd like to get some semantics out of the way. I can't bring myself to refer to this now-defunct effort as "Open CFML" because it's such a huge misnomer. Frankly, we never referred to the committee as "Open CFML" so I suspect the use of that term in Adam's blog post is merely FUD/scare tactics that suit his purpose. (Saying Open CFML is dead sure has impact, don't it?)

The CFML Advisory Committee was anything but open. There was no communication with the CFML community as to what was going on with the effort, there was no way for the community at large to participate, and suggestions by myself and others to update the wiki regularly with our progress and have an open mailing list that anyone in the community could at least read were continually shot down. Given all this it's not surprising the effort ultimately failed, because openness always wins in the end.

Now for the timeline of the CFML Advisory Committee and why things went wrong from my perspective.

In the beginning ...

When I was invited to join the CFML Advisory Committee I was excited because I originally thought the effort was important for the future of CFML. The CFML landscape changed dramatically with the introduction of two open source CFML engines, so it seemed logical that the interested parties would want to get together and discuss a certain level of standards for the language. It's also something that the CFML community was clamoring for, at least initially, because of concerns over code portability between the various engines.

After getting up to speed on things and having discussions via the closed mailing list as well as a couple of conference calls, it became quite clear to me that the effort wouldn't be able to survive the politics. Even given my valid pessimism, I decided to continue on in earnest, hoping for the best but expecting the worst.

Here comes a bit of dirty laundry, but I think it's necessary for people to understand what was really going on behind the scenes. Adobe's participation and level of effort during their involvement with the committee was incredibly lackluster. The committee had conference calls monthly in the beginning, but after Adam didn't show up for three calls in a row, it seemed rather pointless to continue to schedule them. The email traffic on the closed mailing list would go in fits and starts, and in many cases months would go by with no traffic at all.

To cite but one example of Adobe's lack of effort, the way the committee was attempting to organize the language was to use a Google spreadsheet, with columns for the CFML tags and functions on the left, and then a column for each engine indicating whether or not it had the tag or function. There were then columns for each member of the committee to indicate if they thought the particular tag or function should be "core," "extended core," or "vendor specific" as far as the eventual language specification was concerned.

As you can imagine simply organizing the spreadsheet took a great deal of time and effort, to which many members of the committee contributed. Each vendor was tasked with entering their engine's tags and functions. OpenBD and Railo provided their information quite promptly, and I think it was Rob who did the Lion's share of getting things organized initially, but Adobe's column was incomplete for weeks. Finally I took a day or so and added/corrected all the Adobe functions and tags. That at least got things to the point where we could vote.

When it came to voting, Adobe failed to complete this effort as well. To put things in perspective voting took about an hour, but Adobe couldn't seem to find that hour to input their votes. First it was the CF 9 release, then it was MAX, then ... who knows. Bottom line is it never got done. Everyone involved with this effort is incredibly busy, yet everyone but Adobe made the time to vote.

Lack of Accountability Means Lack of Commitment

After weeks turned into months and the voting was still waiting on Adobe, I believe it was Peter who made the modest proposal of setting deadlines for votes. If someone didn't meet the deadline then we'd simply indicate the person didn't vote and proceed with the votes we had. Everyone paid lip service to having deadlines, but even while discussing deadlines Adobe reserved the right to ignore the deadlines if they were "busy." Again, we're all busy. Either the effort is worth your time or it isn't.

I also suggested repeatedly that the whole specification and voting process be open to the public. The members of the committee were selected to represent the CFML engines and the CFML community, but we don't necessarily have all the best answers, and at a minimum the community at large should have been able to see the process as it unfolded. But that would have meant both commitment and accountability on the part of everyone involved, and in the case of certain members of the committee the commitment clearly wasn't there. Having accountability--let alone public accountability--wouldn't work in their favor.

In the end the incredible lack of progress led everyone to agree to simply codify what was in Adobe CF 8/9 so we could get past the voting roadblock and move on. (Keep that decision in mind; it backs up an important point I'll make later.)

Conspiracy Theories Debunked

Here's where things get really bizarre, so please don your tin foil hats and try to stay with me.

Adam mentions the CFML Conventional Wisdom group in his post, which is an effort Alan Williamson started in order to foster public discussion of the CFML language. Personally I think an open discussion list should have been an arm of the CFML Advisory Committee from the start.

To quote Adam's post, "At the very least, this explained why Peter so abruptly resigned." I'm not going to speak for Peter, but this is not why he resigned, and his resignation wasn't exactly abrupt. He debated it for a long time, but to call it abrupt reminds me of a scene from "Fletch":

Back to our story. So why didn't I mention the CFML Conventional Wisdom list to the committee? Two reasons.

First, it's a public mailing list, and I found out about it like everyone else did, on a blog post or Twitter or who even remembers where. Alan may have even sent me an email directly to make sure I was aware of it, but it wasn't a big secret. There were no back-room dealings on any of this. Alan saw a need, created the group, and then announced it publicly. Simple as that.

Second, and more importantly, I saw this as a completely separate effort from what the committee was doing. The committee never had a public forum to discuss CFML, and the powers that be on the committee didn't want one. So this provided something the committee didn't, and giving the community a voice in helping to define the language they use is something vitally important in my opinion. Ultimately the Conventional Wisdom list could even serve as a benefit to the committee. Loose ideas could be hashed out, sample code usage could be created, and the results could be submitted to the ivory tower that was the committee.

And a bonus reason: at the time when the Conventional Wisdom list started, the committee was in no way, shape, or form in the business of discussing enhancements to the language. We weren't even able to codify what was already in the language, so for Sean, Peter, or me to bring a CFLOOP enhancement discussion to the committee wouldn't have made sense. The committee wasn't the time (or the place, frankly) to have those sorts of discussions.

The way Adam phrased all of this makes it sound like Alan, Peter, Sean, and I got together and were all conspiring against the committee, and maybe Adam even believes against him personally. Nothing could be further from the truth. Sean, Peter, and I found out about the Conventional Wisdom group when everyone else did, and since people on the committee are supposedly aware of what's going on in the CFML community, I assumed everyone on the committee would have seen it as well. The implication that we were keeping a publicly announced, publicly available list hidden from the committee simply doesn't hold water.

As for my better mouse trap header above, ultimately I think having an open discussion group is the way things should have been from the start. Why not seek input from the community at large? Why not have the discussions out in the open? Seems like a no-brainer to me. If Adobe wants to have enhancement discussions with their customers and among the members of their private programs that's great for Adobe, but that doesn't let the legions of CFML developers in the wild participate in the process.

Again, openness always wins.

Where I Agree

Adam did make a couple of points with which I agree.

"In the end, the community isn't losing much at all with the demise of the OpenCFML board."

I completely agree with this statement. Though I was honored to be a part of it I questioned the effort from the beginning because at the end of the day, Adobe ColdFusion sets the de facto standard for the language. I made that point in my last email to the committee list (which for a very long time was the final email on the committee list), and I don't think anyone would disagree.

I take issue with Adam's follow-up to this statement, but life's too short to nitpick every last detail of what he said. The real beneficiary of this effort was supposed to be CFML developers, but somehow that ideal got lost along the way.

Bottom line here is that CFML developers don't have anything to fear due to the loss of the committee, because the practical value of the end goals were rather dubious from the start. It's in the best interest of the open source engines to be largely compatible with Adobe CF, which they are. We haven't had an official CFML standard before and the world hasn't come to an end, so the cf_apocalypse won't come now.

"Innovation and progress in CFML is driven exclusively by the ColdFusion community."

I suspect Adam and I have very different ideas of what constitutes the "community" and what community really means, but ultimately this is correct. The odd thing here is that before the Conventional Wisdom list was started, there was no single public forum where members of the community at large could discuss what they want to see in the CFML language. So if innovation and progress in CFML is truly driven by the community, they now finally have an outlet.

Setting the Record Straight

Now, for the corrections.

"Matt claimed the OpenBD team was too unorganized to submit tags like CFJAVASCRIPT and CFSTYLESHEET (tags I had hope to include in CF9)."

Pure FUD on multiple levels. I may have said something along the lines of "These tags were added on a whim last week," but that's how open source projects work. If Alan or Andy get an idea, or need something for a project they're working on, they'll create the tags and release them in a nightly build. We then get feedback from people actually using the new features and refine as needed. That in no way means the OpenBD team is disorganized. It differs from proprietary software development, sure, but calling that process "disorganized" would be the equivalent of me calling Adobe "lazy" because they only have a new release every two years. Apples and oranges.

CFJAVASCRIPT and CFSTYLESHEET were added to OpenBD, and Adam's response when he found this out was apparently to take it as an affront because we didn't run the idea by the committee first. Adam seemed to continually and conveniently ignore the fact that OpenBD is an open source project, so Adobe or anyone else can see what we're doing every step of the way.

Furthermore, it was agreed upon by all members of the committee that tags and functions developed in specific engines would be brought to the committee only if their creators wanted the language enhancements to be considered as "core" in the CFML specification. We didn't consider CFJAVASCRIPT, CFSTYLESHEET, and some of the other innovations in OpenBD as "core" CFML, so we didn't officially submit them. But again, the source code is open. If Adobe saw something in OpenBD they thought made sense to be core to CFML or to add to ColdFusion, they could have brought it up and we could have discussed it.

And let's talk about what "submitting a tag" to the committee even means. I'm not sure what exactly I was even supposed to "submit"--the tags were out there in the OpenBD source along with documentation as to how they are used, so wouldn't it make sense that if Adobe was interested in considering those tags for ColdFusion they could read the docs and ask about it on the committee list? If you get the sense from Adam's post that there was some rigorous formal process that OpenBD was somehow subverting, don't. There was no such defined submission process in place.

Finally, the "tags I had hope[sic] to include in CF 9" bit is completely bogus. Yes, Adobe did make some changes to CF 9 (specifically CFSCRIPT if I remember correctly) based on the committee's recommendations, and I applaud them for that, particularly given that CF 9 was nearing the end of development at that point. They ignored plenty of other recommendations, and the reason for that--the real bottom line here--is that CF 9 was largely baked by the time the committee was even having these discussions. So to point a finger and say CFJAVASCRIPT and CFSTYLESHEET didn't make it into CF 9 because I failed to make an official submission to the committee is false on numerous levels. We didn't consider them to be core to the language, the code and spec were available from day one, and adding this new functionality to CF so late in the development process likely wasn't going to happen anyway.

"Sean claimed that Railo wanted to wait a version (or two) to see how new Railo tags were accepted by the community before making a formal recommendation."

Again, this is how open source projects work. Did Adobe expect that the open source engines will stop following the process that is best for their projects and users, and hit the brakes on the rapid pace with which new features are added, to ask the committee's permission before making enhancements to their engines? Does it not make sense--and ultimately benefit Adobe--if the open source projects introduce new features to CFML and let the community kick the tires before finalizing the feature? That saves Adobe time in the future if they decide to implement these features, because a lot of the questions surrounding the new features and how they should work will already have been answered.

I'm at a loss to see what the real issue is here. OpenBD and Railo are both open source, both have nightly releases, both have public roadmaps ... everything's always available for anyone to view. I think ultimately this comes down to a culture clash between open source projects and proprietary products, which was probably partially to blame for the failure of the committee's efforts.

"As a community, we never needed the OpenCFML board to guide or document feedback."

I give this one a "thumbs sideways." We didn't need the CFML Advisory Committee specifically to serve this function, but I don't see Adobe doing anything to foster open language discussions in a public forum either. Perhaps that isn't their job; they focus on finding out what their paying customers want, and no one can fault them for that. In similar fashion the open source projects get continual feedback from their users and make changes accordingly.

I do think it's important that there be some avenue for people to discuss CFML as a language in an engine-agnostic way, however, but that was as simple as creating a Google Group. It's a much better solution and will yield far better results than the committee ever would have.

"I really want to thank Ben, Rob and Ray for the work they put into the OpenCFML."

... but no one else. Not Sean for making valiant efforts to keep things going even when the committee was at its lowest points, and not any of the rest of the people who participated far more than anyone from Adobe, and particularly Adam, ever did. If anyone questioned Adam's real attitude towards the committee that statement pretty much sums it up for me. He was never interested in setting politics aside and working collaboratively to create a CFML language spec, and apparently the only efforts that matter are the ones made by the people in his camp. "You're either with us or you're against us" has been proven to be a very divisive attitude, and it's one that ultimately isn't good for the community as a whole.

"As far as I am concerned, the ColdFusion ACPs will be the CFML Advisory Panel for ColdFusion X and beyond. We'll be asking them to review and sign-off on all of our language enhancements (very soon)."

So this at least defines what "community" means to Adobe, and helps to illustrate that they never had any interest in helping to define CFML as a language outside of their own product. That's fine, and makes perfect sense coming from a proprietary software company, but leads me to the conclusion that the CFML Advisory Committee was a PR stunt to begin with. Adobe's heart was never in it, they were just trying to get out in front of the open source CFML revolution.

In Summary ...

The goal of Adam's post is patently obvious: to blame everyone but himself and Adobe for the failure of the CFML Advisory Committee. His rhetoric sounds almost McCarthy-esque. Get people focused on a common enemy--real or imaginary--and they'll become oblivious to little things like logic and the truth.

Let me be clear: Adobe's lack of participation and paranoia over the supposed malfeasance of Railo and OpenBD are, from my perspective, a massive part of what killed the CFML Advisory Committee. I'd have a lot more respect for everyone involved if we could have collectively decided to end the effort, made a joint statement, and parted ways amicably. But for Adam to post a truth-challenged version of events out of the blue, while not surprising, is in very poor form.

And That's All I Have to Say About That

I've said my peace and then some at this point. Feel free to comment, and if you have any specific questions you think I can answer, I'll be happy to do so. If, however, your comment is of a "he said/she said" nature or intended solely to inflame the situation further, don't be surprised if I don't respond. Adam gave his version of the story, I've given mine in abundant detail, and everyone can continue to speculate on what went on behind the closed doors of the committee. If you care to, anyway. I'd certainly hope you have much, much better ways to spend your time. ;-)

To me, it's not worth dwelling on all of this. The CFML Advisory Committee will go down as an interesting side-note in the annals of CFML history, and people looking back will wonder why we even tried in the first place. I've been asking myself that very question for quite some time.

As a corollary to Sean's post about running Railo, OpenBD, and ColdFusion on JRun, I thought I'd outline my preferred development environment these days, which is to run all the necessary CFML engines on Apache Tomcat. Note that this approach will work equally well on Jetty, JBoss, GlassFish, or more or less any servlet container or JEE server you choose.

Great minds think alike because coincidentally enough, Dave Shuck also has just published two blog posts (part 1, part 2) about setting up a similar environment. I figure I'll throw mine out there as well because the more information available the better.

So why not use JRun? Well, aside from the fact that JRun is getting very long in the tooth at this point, personally (and you'll probably hear me say this in a couple of conference presentations this year), I think the ColdFusion model stands Java on its head a bit, particularly when you do a standalone install of ColdFusion. Yes, it makes it easy to install and configure ColdFusion, but in my opinion it also shields people from how Java web applications actually work, so I've become a big fan of treating ColdFusion like what it is: a Java web application.

This to me makes far more sense than letting ColdFusion and JRun dictate your Java environment. And I think you'll see in this blog post that "installing" CFML engines on Tomcat is actually easier than installing ColdFusion. The only even remotely tricky part is installing Tomcat (and in most cases it isn't tricky at all), so let's tackle that first.

As an aside, if you just want to try Open BlueDragon and don't want to bother with the Tomcat installation, just download the Ready2Run Jetty + OpenBD distribution, start Jetty, and you're done!

Installing Tomcat

I'm assuming you already have Java installed, and I recommend Java 1.6 updater 10 or later (updater 11 is the latest) since previous versions had a bug that makes CFC instantiation horrendously slow. So, if the following looks complicated, it's really only because I'm outlining how to get the Java settings correct if you need to worry about it. Chances you won't need to do most of these steps, and once Tomcat's running the CFML piece of this puzzle is dead simple.

First, download Tomcat. As of this blog post the latest version is 6.0.18, and you'll want the "Core" binary distribution. After the download completes, unzip the file you downloaded. Now comes the tricky install process. Oh wait, I forgot--there is no install process! All you have to do is start Tomcat after you unzip it. If you have your Java environment set up correctly Tomcat should find Java fine and fire right up.

To start Tomcat, open a terminal (or DOS window if you must ...) and navigate to your Tomcat directory, then the bin directory. For example if you unzipped Tomcat to /home/yourname/apache-tomcat-6.0.18, you would navigate to /home/yourname/apache-tomcat-6.0.18/bin. (Note that all of this runs perfectly well on Windows, and though I would never recommend using Windows for anything, you do not have to use Linux to get any of this to work.)

Once you're in the bin directory, run the startup.sh script (./startup.sh) and you'll see some output similar to this:

Using CATALINA_BASE:   /home/mwoodward/apache-tomcat-6.0.18

Using CATALINA_HOME:   /home/mwoodward/apache-tomcat-6.0.18

Using CATALINA_TMPDIR: /home/mwoodward/apache-tomcat-6.0.18/temp

Using JRE_HOME:       /usr/share/java/jdk1.6.0_11

As long as you see something similar everything's likely fine. If you see errors, the most likely culprit is that Tomcat can't find Java. You can either set a JAVA_HOME environment variable, or you can explicitly tell Tomcat where to find Java by adding the JAVA_HOME location to the catalina.sh script in the bin directory. Open catalina.sh in your favorite text editor, and after the big block of comments at the top of the file (denoted with # signs), add the following line:

JAVA_HOME=/path/to/your/jdk

Note that this should be the path to your JDK's home directory, not to a directory such as lib, etc. inside the directory. In my case I have Java in /usr/share/java/jdk1.6.0_11 so that's the value I use for JAVA_HOME. Save catalina.sh and run startup.sh again and everything should work now.

Check to make sure Tomcat is running by browing to http://localhost:8080 You should a page confirming that Tomcat is configured correctly.

Once Tomcat is running, since Open BlueDragon is a standard Java WAR (web application archive) file, "installing" OpenBD on Tomcat really just means copying a file to Tomcat's webapps directory so the WAR file is deployed. A WAR file is actually the same format as a JAR file (which is essentially a ZIP file ...), but it has an XML file that tells servlet containers how to deploy the application.

Here are the installation steps for OpenBD:

1. Download the Open BlueDragon WAR ("J2EE Standard WAR") file from http://openbluedragon.org/download.cfm


2. Copy the WAR file (which unless you change it is called openbd.war) to /path/to/tomcat/webapps


3. Wait a few seconds for Tomcat to auto-deploy the WAR file, and browse to http://localhost:8080/openbd to see a test page:

As for where to put your CFML files, just put them in /path/to/tomcat/webapps/openbd (or whatever you called your context path), and of course all URLs for this instance will include the context path in them. I won't be covering how to run Tomcat on port 80 or hook things into Apache in this blog post, but I'll cover that in a future post.

Installing Railo

To install Railo you follow the exact same steps as above with Open BlueDragon:

1. Download the Railo WAR from http://railo.ch/en/index.cfm?treeID=224 -- you want the WAR file under "Railo Custom" at the bottom of the page


2. Copy the WAR file to /path/to/tomcat/webapps. In this case since the file name includes the version number, I did a cp railo-3.0.2.001.war /path/to/tomcat/webapps/railo.war, which will make the context path "railo"


3. Wait a few seconds for Tomcat to auto-deploy the WAR file, and browse to http://localhost:8080/railo to see a test page:

As with OpenBD above, just put your CFML files in /path/to/tomcat/webapps/railo to run them on Railo in the railo context path.

Installing ColdFusion

ColdFusion is a bit of a different beast since Adobe doesn't distribute a standard WAR file, but luckily you easily can generate one by running the installer. The steps below are when you run the installer on Linux but the same principles apply on other operating systems. Let's generate a WAR file for ColdFusion.

1. If you don't have it handy, download the developer edition of ColdFusion from http://www.adobe.com/support/coldfusion/downloads.html


2. Run the installer (note on Linux you need to run the installer as root)


3. Accept the license agreement (which is really fun to page through on the console installer--I think if you hit enter 28 times that will get you to the "Do you accept?" prompt ;-)


4. Select Developer Edition (or use a serial number if you prefer)


5. KEY STEP: Choose an installation type of "J2EE Configuration (WAR file)"


6. Select the stuff you don't want to include in the installation. I typically uncheck all four choices (docs, LiveCycle, search services, and start on init) when I generate a WAR


7. Choose the installation directory or accept the default


8. Enter the admin password


9. Choose to enabled or disable RDS. I find it's handy to have RDS on development instances so you can use the Eclipse tools to interact with the datasources.


10. Enter the RDS password


11. Confirm the installation selections and continue


12. Wait a minute or so for the WAR to be generated

At the end of this process you have a CF 8 WAR file sitting in your install directory (which by default on Linux is /opt/coldfusion8). Now the installation is more or less as above with OpenBD and Railo since we have a standard WAR file we can deploy on Tomcat:

1. Copy the cfusion.war file into /path/to/tomcat/webapps As indicated above, this will mean your context path will be "cfusion" unless you rename the WAR file while copying it.


2. Wait a few seconds for Tomcat to auto-deploy the WAR file


3. Browse to http://localhost:8080/cfusion to complete the installation process for the WAR.

Note that you only have to go through the 12-step program above to generate the WAR once, unless you want to change the installation options. So when you need another instance of ColdFusion on Tomcat, just copy the WAR file over again and give it a different name (and hence a different context path) from any other instances.

If this matters to you, please be aware that for some reason ColdFusion isn't officially supported on Tomcat. Why is a bit of a mystery since Tomcat is the servlet container used in JBoss, and in my experience ColdFusion runs just fine on Tomcat. I only bring it up if you're in an environment where official support matters.

Why Do This?

You now have Tomcat running and can easily develop and test on Open BlueDragon, Railo, or Adobe ColdFusion. To me that's reason enough to use a development setup such as this. Also based on my experience helping people get this type of environment set up, it really does start to open up people's eyes to what's really going on under the hood with ColdFusion. Yes, if you do the multi-instance installation of ColdFusion you do get some server management features you don't get otherwise, but based on how I'm using ColdFusion these days, I simply don't need those features, particularly on development.

What I do need, on the other hand, is the ability to develop on both ColdFusion 8 and (increasingly) Open BlueDragon, so rather than trying to shoehorn OpenBD into the ColdFusion/JRun environment, I prefer to use a standard Java servlet container such as Tomcat and put all the CFML engines and instances I need on Tomcat.

Next Steps

You're probably already wondering how to get things to run "for real," meaning eliminating the port number and context path for your users. This can be done several different ways, so I'll cover some options in future blog posts. In the mean time, check out Dave's blog posts (links above) for some info on setting things up with Apache and mod_jk, which is one way to go. You can also change the port Tomcat runs on, or proxy from Apache out to Tomcat for CFML sites, so there's no shortage of ways to set up more or less any configuration you want.

Comments