Coder's Revolution

Do you want a revolution?

Category Filtering: 'Railo'

Exciting New Features In The CommandBox 3.1.0 Bleeding Edge

ColdFusion, CommandBox, Lucee, Railo
Hi all, we've been hard at work on ForgeBox 2.0 and the corresponding CommandBox CLI features that focus on your productivity in publishing packages and keeping them up to date as well as tracking all the versions of your dependencies.
 
For starters, the ForgeBox 2.0 isn't published yet in production.  If you download the bleeding edge of CommandBox (3.1.0) you will be pointing to our stage server.  it's a recent backup of production data, but since the new ForgeBox site is a rewrite on top of an updated data structure, it needs to be a separate database.  So, feel free to use it, but remember you're not going to be installing or publishing to the live ForgeBox site yet until we roll out this release.
 
Download CommandBox 3.1.0 here:
 
Running "upgrade --latest" will also give you this URL.
 
Here's an overview of the new stuff for you to try out:
 

New ForgeBox 2.0 API

 
The API has been rewritten as a fresh ColdBox module using ORM and a new database.  You probably don't really care since the endpoints are mostly the same, but nonetheless it all needs tested to make sure we didn't break anything.

 

Track more than one version of your package at a time in ForgeBox

 
As part of the new data structure in the ForgeBox site, a package no longer has a single version, but as many versions as you like.  Each version stores its own download URL, and box.json data.  The new ForgeBox.io site will show these.  For now you can see the available versions from the CLI with the "forgebox show" command:
 
CommandBox> forgebox show coldbox
ColdBox Platform ( Luis Majano, [email protected] ) *****

The ColdBox MVC Platform manual can be found here: http://coldbox.ortusbooks.com/ 

Type: MVC
Slug: "coldbox"
Summary: The ColdBox Platform
Versions: 4.3.0-snapshot, 4.2.0, 4.1.0, 4.0.0, 4.0.0-rc, 3.8.2, 3.8.1, 3.8.0, 3.7.0

...

 

Create user from CLI

 
Also part of the new API is the ability to create a new ForgeBox user right from the CLI.  Run the "forgebox register" command to get started.  Feel free to test this, but if you already have a ForgeBox user, you can just skip to the next step and login.  The confirmation E-mail is bypassed right now for testing.  If you forget your password on our stage server, there's not currently a way to reset your password, but there will be.  

 

Authenticate from the CLI

 
Once you have a confirmed user, you can run "forgebox login" to authenticate your account.  This will store your API key in a CommandBox config setting.  You can see it with:
 
CommandBox> config show endpoints.forgebox

 

Bump tags Git repo

 
This is a nice feature that npm does.  When you use the "package version" command (aliased as "bump"), if you are running the command in a Git repository and the working directory is clean, the CLI will create a tag for you that's named after the version and commit it.  You can supply a custom message if you like each time or as a global setting and even turn the entire feature off with a config setting flag.
 
CommandBox> bump --patch
CommandBox> bump --minor message="Upgrading to ${version} because I want to"
CommandBox> config set tagVersionMessage="My default tag message"
CommandBox> config set tagVersion=false

 

Publish packages from the CLI

 
This is where it really gets fun.  You basically don't ever need to touch the forgebox website again if you don't want to!  The "forgebox publish" command (aliased as "publish") will add a new package to ForgeBox, or update an existing one (that belongs to you).  If the local version number is different, a new version will be created in ForgeBox.  Usually you would use the bump command above right before publishing.  Remember, ForgeBox does not store your actual package files like npm.  We just point to your download location.  We've been optimizing this as much as possible to work seamlessly with a Git repo. When you publish a package, this data is sent to the server:
 
  • Your box.json.  Specifically
    • Package name
    • slug
    • version
    • type
    • location (this is where to download your package from and can be an HTTP URL or ANY VALID package ID such as "repoUser/repoName#v1.2.3")
    • etc
  • The contents of your readme[.txt|.md] file one of those exists
  • The contents of your changelog[.txt|.md] file one of those exists
  • The contents of your instructions[.txt|.md] file one of those exists
  • Your API key config setting to authenticate
That's it.  Once you run this command, you can run "forgebox show my-package" to confirm it's there.  
Any updates to your readme, title, etc will overwrite the old data.  
If you change the slug, a new package will be created.  
If you change the version, a new version will be added to the existing package.
 
I've run a backfill on the new ForgeBox database to create a single version on every package equal to whatever the last version was saved in ForgeBox.
 

Semantic Versioning support

 
This is huge and goes hand-in-hand with the new versioning.  One of the biggest complaints about ForgeBox is you couldn't say "install [email protected]" if the latest version of foo was actually 2.0.0.  Well, now you can.  Any version on a ForgeBox package which is typed after an @ sign for the install command or as the "value" of your dependency in box.json will now be used to look up the correct version in ForgeBox (assuming it exists) and the proper download URL will be used to download and save it in artifacts.  Remember, the download URL comes from the "location" property of the box.json and can be any valid packager ID.
 
And that's not all-- we now fully support the entire implementation of npm-style semver ranges.  That means you tell CommandBox a "fuzzy" range of versions you're ok with and it finds the best match.  Stable versions are determined by the existence of a pre-release ID like "-alpha".  Therefore 1.2.3-rc is a pre-release but 1.2.3 is a stable build. 
 
Here's some examples:
# Latest stable version
CommandBox> install foo

# Same as above
CommandBox> install [email protected]

# latest version, even if pre release (bleeding edge)
CommandBox> install [email protected]

# A specific version
CommandBox> install [email protected]

# Any version with a major number of 4 (4.1, 4.2, 4.9, etc)
CommandBox> install [email protected]

# Any version greater than 1.5.0
CommandBox> install foo@>1.5.0

# Any version greater than 5.2 but less than or equal to 6.3.4
CommandBox> install "foo@>5.2 <=6.3.4"

# Any version greater than or equal to 1.2 but less than or equal to 3.2
CommandBox> install "[email protected] - 3.2"

# Allows patch-level changes if a minor version is specified. Allows minor-level changes if not.  (2.1.2, 2.1.3, 2.1.4, etc)
CommandBox> install foo@~2.1

# Any greater version that does not modify the left-most non-zero digit.  4.2, 4.3, 4.9, etc
CommandBox> install foo@^4.1.4

 

And finally, the "update" command really works now as it takes the semver range stored in your box.json into account.  For example, if you have a dependency installed with a version saved of ^2.0.0 it will update you all the way to 2.9.9 but it will never install3.0.0 until you ask it to.  This is because breaking changes come in major versions, but minor releases are supposed to be compatible.
 

Interceptor-based CLI scripts

 
Moving along, we've borrowed another idea from npm's run-scripts.  We allow a struct in your box.json that can define named scripts comprised of CommandBox commands.  We've hooked these scripts up to all the built-in interception points in CommandBox (and added a few new ones) so you can prescribe arbitrary commands on a package-by-package basis to run any time you bump a package version, publish to ForgeBox, start a server, or exit the CLI.
 
Here's an example box.json file:
 
{
  "name" : "My Package",
  "slug" : "my-package",
  "version" : "1.0.0",
  "scripts" : {
   "postVersion" : "package set location='gitUser/gitRepo#`package version`'"
   "postPublish" : "!git push'"
  }
}

Any time I bump a package version, I'll update the location property to have the latest version for the Git tag.

And when I publish my package in ForgeBox, I'll automatically push my changes to Github (assuming I have a Git client installed at the command line)

 

System log command

 
This is a small one, but the new "system-log" command outputs the path to the CommandBox log file. You can use it creatively by piping its output into other commands:

 

CommandBox> system-log | open
CommandBox> system-log | cat
CommandBox> system-log | tail

 

Lots of little bug fixes

 
There's a number of small things we've fixed here and there that you can see in JIRA.
 

Coming very soon- multi-server support!

 
We are also working hard on the ability for you to not only start up Lucee 4.5 servers but also:
  • Adobe CF 
  • Lucee 5.0
  • Railo 4.2
  • Any random WAR you want 
This will be part of the 3.1.0 release and I'll post here again when it's ready to try out on the bleeding edge.
 

Streamlined Productivity

I'll leave you with the FULL set of commands necessary to start from complete scratch, sign up for ForgeBox, authenticate, create a package, and publish it for all the world to install!

# Create user (first time only)
CommandBox> forgebox register username password [email protected] firstName lastName
CommandBox> forgebox login username password

# Create package/git repo
CommandBox> mkdir mypackage --cd
CommandBox> !git init
CommandBox> package init slug=my-package type=modules location=gitUser/my-package
CommandBox> bump --minor message="Initial Commit"

# Publish it
CommandBox> !git remote add origin <git url>
CommandBox> !git push
CommandBox> publish

# Viewable and installable by the world!
CommandBox> forgebox show my-package
CommandBox> install my-package

 

0

CFML & CommandBox, Tools Of Biblical Proportions

ColdFusion, CommandBox, Lucee, Railo, Technology

In the beginning was the Web, and the Web was with CFML, and the Web was CFML. It was with CFML in the beginning. Through it all websites were made; without it no websites were made that had been made. In it were tags, and those tags were the productivity of all programmerkind. The productivity shone in the darkness, and the darkness did not overcome it.

Ok, maybe I'm overstating CFML a bit, but when it was created it was revolutionary.  It redefined how websites were built and set the bar for other web programming languages.  And though CFML led the pack for a while, there were soon others to follow.  These languages were also productive, came with compelling frameworks, and made building sites fast and fun.  Many of these servers were also free and open source and around them large communities grew.  

3

Railo And Lucee: Hunka Hunka Burning Questions

CFML, ColdFusion, Lucee, Railo

Well, the cat is out of the bag now.  Railo, the free open source alternative CFML engine to Adobe's ColdFusion Server has been forked and reborn as a new product called Lucee.  I was lucky to be part of the launch party (via webcam) that happened this morning in London.  This is a major event in the tiny CFML eco-system and it's understandable that there's a  lot of questions floating around and confusion on just exactly what has happened.

There are a lot of large open source projects that have forked before.  For instance, MySQL spawned MariaDB, OpenOffice, begat LibreOffice, Hudson turned into Jenkins, and even recently Node.js was forked int IO.js.  In some cases, the original project continues alongside the new one.  In other cases, the old project basically sits there and everyone stands up, shuffles over to the new one, sits down and continues as if nothing happened.  I personally think Lucee is going to be more like one of those.

I'm throwing together this post to address some questions that have come up over and over again today.  Hopefully they will be answered more fully by the Lucee team as they dig out of this major announcement, but in the mean time this is a compilation of some answers I've given multiple times today around the Internets.  Please note, I am not speaking on behalf of Lucee nor Railo, these are my opinions and observations mixed with some info I've picked up along the way.  I'll happily accept corrects or clarifications in the comments.

12

CFML, Good Discussions, And Misinformation

ColdBox, ColdFusion, CommandBox, General, Java, Object Oriented Design (OOP), Railo, Technology

So this blog is a bit of a spill over from a Twitter conversation I had today with Stefan Mischook, a PHP programmer and maker of all sorts of training videos at www.studioweb.com and www.killersites.com.  A few years ago, Stefan uploaded a video blog to YouTube titled "Should you learn Coldfusion?" (sic) where he presented a not-so-glowing review of ColdFusion through the lens of circa 2003.  I've seen the video before come up in YouTube searches.  Part of that is a testament to the pathetically small amount of actual CFML content on YouTube.  While I've recorded a number of screencasts and webinars that are posted online, they're all on Vimeo or Adobe Connect so alas I'm not contributing to that specific site.  

15

ColdFusion And Railo SuperClass's Switch "this" Between pseudo-Constructor and Init()

ColdFusion, Railo

I noticed an interesting behavior this week that was a little unexpected.  The repro case involves two CFCs-- one extending the other and involves where the "this" reference points to.

Constructors

ColdFusion has two types of constructors-- that is, ways to run initialization code upon the creation of the component.  The first way is called the pseudo-constructor and basically refers to ANY code inside the component that is not part of a method. That was the only way to run initialization code back when CFCs first came out in CFMX 6.  The second way is via a method called "init()".  This was a widely-used convention for years before CF9 started automatically calling it for you when you used the "new" keyword and "entityNew()" function.

Narcissism or Schizophrenia

Sometimes components want to know about themselves or even talk to themselves.  Heck, I wrote a CFC last week that just won't shut up!  That's why there is a keyword called this available inside every CFC.  This is the same as the external references held by the code that created the component instance.  The pseudo-constructor and init() method both have access to this.

The Code

Here is our super class, or base class.  

animal.cfc

component {
	
	writeOutput( 'Animal pseudo-constructor. "this" name: #getMetadata( this ).name#<br>' );
	
	function init() {
		writeOutput( 'Animal init. "this" name: #getMetadata( this ).name#<br>' );
	}	
}

Here is our sub class or concrete class that is a more specific type of animal.  

dog.cfc

component extends='animal' {
	
	writeOutput( 'Dog pseudo-constructor. "this" name: #getMetadata( this ).name#<br>' );
	
	function init() {
		super.init();
		
		writeOutput( 'Dog init. "this" name: #getMetadata( this ).name#<br>' );
		
		return this;
	}	
}

Remember the new operator will automatically call the init() constructor method.

index.cfm

<cfset new dog()>

So as you can see, each component logs the name of the component as reported by getMetadata() in both the pseudo-constructor and init() constructor.

The Behavior

Here is the output.  It is the same for Railo 4.2, CF9, CF10, and CF11.

Animal pseudo-constructor. "this" name: animal
Dog pseudo-constructor. "this" name: dog
Animal init. "this" name: dog
Dog init. "this" name: dog

The this reference in both init() methods point to the "dog" component that I'm creating.  However, the pseudo-constructor code in the base class "animal" has a this reference to "animal", not "dog". What bothers be about this is:

  • The this reference changes unexpectedly in the base class
  • There is no way for the base class to access the concrete class in its pseudo-constructor
  • I can't find any Railo or Adobe ColdFusion docs that reference this behavior to show if it's expected or not.

That second bullet point is specifically what was tripping me up because the base class can't get a reference to the actual component being created.  Sean Corfield mentioned on Twitter that a base class should not know about it's sub classes, but use polymorphic methods. However that DOESN'T WORK since the base class's pseudo-constructor has no reference to the sub class at all.   To test this, put a speak() method in the dog CFC:

function speak() {
	writeOutput( 'Woof!<br>' );	
}

Now, try to call that from the base classes pseudo-constructor.  

speak();

No matching function [SPEAK] found

Of course, this works from the init method, but my point is I think it should work in both constructors.

Another interesting note is that if you save a reference to this in the base pseudo-constructor and check it later, it will have changed to the concrete class.  This made debugging a pain since I originally started appending references to an array in the request scope and dumping them after the component creation which yielded different results than the state of the this references at the point in time when the constructors were executing.

Conclusion?

I mentioned this on Twitter and got a couple different responses. What do you think?  Should CFCs handle the this reference the same between their pseudo-constructor and regular constructor?

 

10

Adobe Product Security Incident Response Team (PSIRT) On ColdFusion And HeartBleed

ColdFusion, General, Networking, Railo, Security

The world is abuzz with the OpenSSL "heartbleed" bug and the ColdFusion community has also been going 'round about it too.  Firstly, a server (like Apache, Nginx, Tomcat, etc) can be exploited by a client on a hackers machine requesting an SSL connection.  In addition, a client (CURL, wget, CFHTTP, etc) can be exploited if connecting to a malicious SSL endpoint.  So basically, the bug has the ability to flow both ways. 

For most CF sites, they are using IIS, Apache, or Nginx to serve content so ColdFusion has no bearing on the vulnerability from that end.  Any CFML application, however, can connect to a malicious SSL endpoint.  Of course, it only matters if the OpenSSL library is specifically being used.  Any other SSL implementation is safe.

To date, neither Adobe or Railo have yet to make public announcements via security bulletins or their official blog.

UPDATE April 17: Railo responds here.

UPDATE April 18: Adobe responds here:

There have been a handful of less "official" conversations in mailing lists and Twitter.  As best I can tell, neither Adobe ColdFusion or Railo use OpenSSL and therefore are safe.  Of course, any other parts of your web stack (even bundled libraries) might use OpenSSL.  Gert from Railo has promised a blog entry "soon" to address the issue regarding Railo.  There has been some complaining about the lack of official word from Adobe, and my understanding is that the ColdFusion team's hands are tied by the Adobe PSIRT who are the only ones allowed to comment publicly on security matters.

 The general consensus is they could certainly say something, even if it was simply, "Hey, we're looking into it and will get back to you soon".  That as it is, I E-mailed Adobe's PSIRT myself and got a reply that seems as close to an official reply as they are willing to provide at this point though I'm unclear why they're talking about it one-on-one but refraining from public statements.  For the sake of those who haven't E-mailed PSIRT, I will post their reply here for the benifit of the community until something official comes out.  Also, for funsies, I'll post my original E-mail plus my followup.  If I hear back again, I'll update this post.


From: Brad Wood
To[email protected]
Date: Wed, Apr 16, 2014 at 5:45 AM
SubjectAdobe ColdFusion and Heartbleed

Dear Adobe PSIRT team, 

 
I would like to encourage you to please make a public announcement regarding Adobe ColdFusion and if it is vulnerable to the latest OpenSSL "heartbleed" bug. This is a very significant bug that has people around the world scrambling to patch their software.  Even if Adobe ColdFusion is not susceptible to the recent "heartbleed" bug I would strongly suggest making an announcement on your blog to state that or authorize the ColdFusion team to do so on their blog. 
 
Many people in the CF community have noticed the silence on this issue and an official announcement really needs to be made in order for your customers to feel safe and to verify with their employers that they have all the patches they need.  Communication is very important and I hate to see the Adobe ColdFusion team getting beat up for not addressing this issue publicly on their blog.  Please authorize them to make some kind of statement on this.
 
Thanks!
 
~Brad

From: [email protected]
To: Brad Wood
Date: Wed, Apr 16, 2014 at 1:39 PM
Subject: RE: Adobe ColdFusion and Heartbleed

Hello Brad,

 

Thank you for contacting us.  We appreciate your feedback.  Please note that ColdFusion does not use OpenSSL. However, customers who are using an external web server with their ColdFusion deployment (ex. Apache) should test for CVE-2014-0160. If affected, customers should follow the recommendations provided in the OpenSSL security advisory, available at https://www.openssl.org/news/secadv_20140407.txt. Adobe

also recommends consulting the ColdFusion lockdown guides for security best practices:

https://www.adobe.com/content/dam/Adobe/en/products/coldfusion-enterprise/pdf/cf10-lockdown-guide.pdf

http://www.adobe.com/content/dam/Adobe/en/products/coldfusion/pdfs/91025512-cf9-lockdownguide-wp-ue.pdf

 

We hope this information is helpful.  Please let us know if you have additional questions.

 

Thank you,

Adobe Product Security Incident Response Team


From: Brad Wood
To[email protected]
Date: Wed, Apr 16, 2014 at 3:13 PM
SubjectAdobe ColdFusion and Heartbleed

Dear PSIRT Team, 
 
Thanks for the reply.  I appreciate the links and concern.  Let me be very clear though-- I am not asking about this for the sake of my servers, I am letting you know that Adobe needs to make a public official statement on the matter for the entire community to see.  Even if your blog entry said nothing more than what you put in your E-mail reply that would be great-- but the community has noticed the lack of public response by Adobe to this matter and it's reflecting quite poorly on your PR.
 
If the PSIRT team doesn't have time to make a quick announcement, please authorize the ColdFusion team to put out a blog post.  This would do a lot for the community as silence breeds distrust and most every other major technology stack have already addressed their platform publicly-- even if just to say they are not vulnerable.
 
Thanks!
 
~Brad
 

UPDATE April 18:


From: Brad Wood
To[email protected]
Date: Thu, Apr 17, 2014 at 9:50 PM
SubjectAdobe ColdFusion and Heartbleed

Dear PSIRT team,

 
Can you please respond to the comments on my blog made by a community member named "Aaron".  He has listed several binaries that ship with ColdFusion that supposedly use OpenSSL.  His comments can be found here:
 
 
Also, if you haven't seen it-- here is the official response from the Railo team (a competitor of Adobe CF) which categorically addresses the uses of SSL inside Railo server.
 
 
Thanks!
 
~Brad

From: [email protected]
To: Brad Wood
Date:  Fri, Apr 18, 2014 at 2:58 PM
SubjectAdobe ColdFusion and Heartbleed

Hi Brad,

Thanks to you and Aaron for bringing this to our attention.  With your input, we started a deeper investigation of ColdFusion components.  We have also clarified our blog post regarding OpenSSL in ColdFusion (http://blogs.adobe.com/psirt/?p=1085).  Should additional information arise from our investigation we'll provide an update to our blog.

 

Thank you again for your help,

Adobe Product Security Incident Response Team

6

Getting CFML Working On Runnable.com

ColdBox, Railo, Runnable

In my last entry, CFML, Meet Runnable.com For Live Code Sharing, I talked about what Runnable.com is and why it's worth looking into for anyone who's looking for a nice platform to publish live working code samples that people can launch in their web browser.    Today I'd like to cover the steps I took to getting CFML working on Runnable as well as gotcha's and other bits that weren't immediately obvious.  The great thing is, you don't have to know most of this to publish your own code!  Just click on one of my Runnables, click the "Save Draft" button, change the name, description, and code to your liking, and then Publish it!  You don't have to start from scratch; you can spring board off of my work.  For those of you who want to do it your way or are just curious, keep reading.

As discussed in the first post, each runnable is stored as a template of a Linux server called a "container" and is managed by a technology called Docker.io.  When a user comes to the site and clicks a runnable, a unique lightweight "instance" will be spawned from the container template just for that user.  This instance actually runs inside of a master linux instance that it shares resources with, but it is completely isolated from all other instances.  It will also be destroyed when the user leaves their web page.  As such, site users have root access to this instance and can run whatever commands and write whatever code they want, but they are isolated to their instance and securing the runnable is not necessary.

Here's a list of items in no particular order that I wish were documented somewhere on the site when I started:

Getting Started

  • If you want to start from scratch, visit http://runnable.com/new and click "bash". 
  • If you want to start from an existing runnable, view it and click "Save Draft"
  • You will need to create an account to make a runnable, but that makes sense
  • Edit the title of the runnable by clicking the pencil icon.  Make sure you hit save!
  • Edit the description of the runnable by clicking the pencil icon.  Make sure you hit save!  I have put in a suggestion that this allow rich text

Managing Files

  • The folder icon in the upper righthand corner will open a file explorer.  You can created folders and files here.  Click on a file to open it.  
  • Right click on a file and choose "Set Open by Default" for that file to default to being open in a tab when people visit your runnable
  • The editor has decent color coding and does allow you to copy paste in it.
  • The default folder for the file manager is /root.  You cannot change this, but if you ask Runnable, they will
  • The runnable guys can also filter what files and folders show up if you ask them.

Using The Terminal

  • Below is the terminal with a bash prompt.  Hit the icon to the right of the word "Terminal" to pop out into a new full screen tab.
  • You can copy text by highlighting and right-clicking
  • If you edit a command at the shell prompt it will appear as though it has overwritten your text.  Have no fear.  Press the "end" key on your keyboard and it will fix itself.
  • uname -a returns
    Linux runnable 3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 18:16:28 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Installing Software

  • You can use wget to download whatever installers you want
  • You can use apt-get to install whatever packages you want
  • You can install Git and clone repos (This is what I do)
  • As far as the server you set up, the world is your oyster.  Any servlet container, CFML engine, and configuration is valid as long as it runs on Ubuntu.
  • Note, I had issues getting the Railo Linux installer to run.  I have logged this issue with the Runnable guys.
  • I installed Tomcat via apt-get and deployed Railo as a WAR file in the root context.  To do this, delete the folder called ROOT under /var/lib/tomcat/webapps, rename the Railo file to ROOT.jar and place it in the webapps folder.  After a few seconds, Tomcat will pick it up and explode it out.  The /var/lib/tomcat7/webapps/ROOT folder is your new web root.  I asked the Runnable guys to default the editor file explorer to there.
  • If you have them disable Apache, you can bind Tomcat to port 80 but I just set up a reverse proxy so I could use Apache's rewrite module.

Configuring CFML

  • The config for the default Apache site is located in /etc/apache2/sites-available/ in a file called "default".  
  • By default the web root is /var/www.  I changed the DocumentRoot directive and <Directory> tag to /var/lib/tomcat7/webapps/ROOT
  • I also changed the DirectoryIndex directive to index.cfm
  • I created a file called "railo.conf" in the /etc/apache2/conf.d directory.  It is automatically included.
  • Inside I set up my proxy to the standard AJP port:
    <Proxy *>
    Allow from 127.0.0.1
    </Proxy>
    ProxyPreserveHost On
    ProxyPassMatch ^/(.+\.cf[cm])(/.*)?$ ajp://localhost:8009/$1$2
  • Check in /etc/apache2/mods-enabled and if proxy.conf, proxy.load, and proxy_ajp.load aren't listed, enable them with a2enmod
    sudo a2enmod module_name
  • Tomcat web config is located In /etc/tomcat7/server.xml 
  • Uncomment the AJP connector on port 8009
  • The web root is configured in the <host> block.  Check it if you're going somewhere different than the default context.
  • When "running", if you break the page out of the frame, you can access the Railo administrator at the usual URL by adding /railo-context/admin/server.cfm to the end of the URL
  • I didn't set the Railo password, but there's not security concern if someone accesses it since the entire instance is unique to them.

Running Code

  • For a web framework, you don't need to change the "Run cmd" or "Build cmd" options that drop down on the "Run" button.  
  • I would also recommend setting "Only Web" which will not show the terminal window along side the web page output.
  • When the Run button is pressed, a new window will open that hits your instance in an iframe.  A DNS name will be created on the fly that uses a GUID to make it unique.  You can click an icon to open your runnable address directly in the main browser tab.
  • Basically, whatever is spit back on port 80 in the web root is what the user will see.  There is currently no way to have the "run" button target a specific URL or query string, but I have requested that.
  • If everything is set up correctly, you should see your default page rendered.  If you've copied one of my runnables it will just work :)
  • Your sample can have multiple pages that the user navigates between.  You can have an entire site if you want!  I like to have instructions on the first page, and then links to view additional pages that show code running.
  • Your pages can submit forms, upload files-- there really aren't any restrictions.

Gotchas

  • You cannot paste text into the terminal window.  This is VERY annoying.
  • A very slick workaround if you need to download an extremely long URL is to shorten the URL with a URL shortner.  wget will follow the 302 redirect automatically and it's much less typing.
  • You cannot SSH directly to the instance via PuTTy.  I have suggested they allow this.
  • Apache is automatically running and bound to port 80.  The runnable guys can disable that, but you can't.  Whatever you do, it will come back.
  • Port 80 is the ONLY externally-accessible port.  That means you can't run Tomcat on 8080, etc.
  • Tomcat will NOT start by default and there's nothing you can do to fix it.  E-mail the Runnable guys and ask them to change your instance startup script to include Tomcat and they will happily oblige.
  • Tomcat takes a few seconds to spin up and Apache will throw a 503 the first time someone hits it.  I have reported this issue, and in the mean time I placed a custom ErrorDocument directive in /etc/apache2/sites-enabled/default like so:
    ErrorDocument 503 "<meta http-equiv=\"refresh\" content=\"1\">Loading..."
    This overrides Apache's default 503 error page with one that simply says "Loading..." and refreshes every second until Tomcat and Railo are ready to serve requests.
  • Runnables don't have access to public DNS so don't try to CFHTTP to cgi.server_name in your code as it won't resolve. localhost will work. (Ran into this on the HTTP Runner for TestBox)
  • Runnables are case sensitive-- good to remember if you're developing the examples on windows.
  • Your account won't be able to publish at first.  Just E-mail, Tweet, or fill out their contact form and they'll approve you.

Git Workflow

  • I have created a GitHub account called cf-runnable to store my samples: https://github.com/cf-runnable  Feel free to star, fork, and send pull requests to me.
  • I installed git-core with apt-get and clone the repo down into the web root.
  • No authentication is needed via this method so I don't have to worry about accidently leaving an SSH key on the runnable.
  • I created a bash script I called .setup and placed in the web root with this code in it:
    #!/bin/bash
    
    # Clean up dir
    find . ! -name .setup ! -path ./WEB-INF\* -delete
    
    # Clone repo into sub dir
    git clone http://github.com/cf-runnable/$1 ./__tmp
    mv -f __tmp/* ./
    rm -R __tmp

    Git repos can't be cloned into a non-empty directory, so what I do is delete everything in the web root but the script and WEB-INF.  Then I clone the repo into a folder called __tmp, move the files into the web root, and delete the temp folder
    To pull down the code for a runnable sample, simply run:

    $> ./.setup CFML_Templating_With_Tags
  • DON'T DELETE THE WEB-INF FOLDER.  Doing so will remove Railo and CFML will stop processing.  If you do this on accident, remove the entire ROOT folder, and restart Tomcat.  It should redeploy the Railo WAR.  My .setup script is located in the "admin" repo for cf-runnable.  You can easily modify it to point to your own repo.

  • So the process for creating a new runnable is fairly straight forward for me.  I create a new repo and copy over my last project into it including my .gitignore file.  I set up my tutorial on my local install of Railo and when I'm done, commit and push to GitHub.  Then I simply clone another runnable on the site with "Save Draft", edit the title and description and run "./.setup Repo_Name" from the command line and I'm done

Conclusion

That's enough of a brain dump for now.  Runnable is basically as flexible as you could want it to be.  Don't be scared away by all the stuff I typed here.  Most of it is already done for you so go play around with one of my runnables and get your feet wet.  I'll be adding more tutorials-- mostly centered around ColdBox and other Box libraries soon.  I think Runnable.com can be a very cool platform for the CFML community to publish example code on.

Here's some of the runnables I've created.  The full list will always be here.

0

CFML, Meet Runnable.com For Live Code Sharing

ColdBox, ColdFusion, GitHub, Railo, Runnable

You may have seen be tweeting about Runnable.com this week.  I've spent a decent amount of time figuring out how their platform works and getting CFML (Railo) running on it.  Basically, Runnable.com is CFLive.net, trycf.com, and JSFiddle.net all mashed up and super cool.  In short, the platform lets developers post any code samples they want for any database/language/framework up on the Internet so other developers can come along and not only read their code, but run it right there in the browser.  It doesn't stop there, other developers and fiddle with the original code and run the new version right there on the site to figure out how it works.  

It's all possible with Docker.io, a cool virtualization platform I just learned about, and Runnable has the whole thing running on top of Amazons EC2.  Basically, each code sample is an entire Linux VM with whatever installed on it that the publisher wanted to set up.  The template of this VM is stored and every time a visitor comes to the site and wants to check out that code sample, a dedicated VM is spun up in seconds just for that user.  Docker.io allows them to simultaneously service hundreds of users because it shares overlapping resources between the VMs so they're very lightweight and come online in seconds.

And since each user gets their own isolated playground, there's no sandbox security to worry about.  In fact, each code page has an emulated bash shell with root privileges at the bottom of the page!  Any local changes made by the visitors of the site, are discarded after they close their browser and the session times out.  The code samples aren't limited to a single file of code-- publishers can create tutorials to demo entire frameworks, with multiple files. Need a database?  Install one.  Need Tomcat? Install it.

So, speaking of Tomcat-- this is where ColdFusion comes in.  Runnable's Twitter account popped into a recent conversation and urged us to get CFML setup, so i took the task and ran with it.  Due to some issue with the Railo installer which they're looking at, I installed Tomcat 7 with apt-get and deployed Railo 4.1 as a WAR file in the root context.  The Runnable guys were super helpful.  They exchanged several E-mails with me and even chatted on Skype for an hour last week answering questions, tweaking my setup, and writing down suggestions.  

I published a proof-of-concept Runnable called CFML Templating With Tags and then a more involved followup called Use WireBox To Create Objects In ColdBox.  I've also created a new GitHub organization called cf-runnable to store all my tutorials.  Feel free to send me pull requests, or ask to collaborate and store your CFML runnables there as well.  Now, what's really, REALLY cool about Runnable is anyone can clone one of my tutorials, make it their own, and re-publish it under their name.  That means no one else has to reinvent the wheel to start putting cool code up on Runnable-- I've already figured a lot of it out and you can springboard off of what I've done, or dive in fresh yourself.

So this is the intro to a blog series I'm going to do how how I got Runnable working with CFML, what little speedbumps I've hit, and how I've been integrating with GitHub to version and host my code.  I have a lot of ideas for Runnable- both improvements for them (like beefier descriptions, and embeddable runnables) and ColdBox-themed tutorials I want to create to let people play around with simple examples and how-to's.  Stay tuned!

3

My cf.Objective() 2014 Submissions & VOTE!

CFObjective, ColdFusion, Railo
Everyone seemed to be tweeting out their cf.Objective() 2014 submissions today so I figured I would as well. However, not being able to fit much in 140 characters, I figured I would stick it in a quick blog entry. Firstly, I like the open voting format this year. it seemed to work well for CF Summit and I didn't hear a single complaint about the content there. After a slow start, I see a good number of additional topics have flowed into the board this last week or so. I've submitted 3 topics of my own for consideration on the cf.Objective() 2014 Trello board. They are thusly:
2

Sean Corfield's Blog Running Ralio

ColdFusion, Railo
I've been following Sean Corfield's nice series, Railo for Dummies on installing Railo, Tomcat and Apache. (Does that make me a dummy?) His latest entry showed the simple steps he followed to convert his blog corfield.org over from Java 1.4 and CF7 to Java 1.6_13 and Railo 3.1.0.009.
1