The Dopefly Tech Blog

<< The Dopefly Tech Blog Main page

Thoughts on calling ColdFusion from the command line

posted under category: ColdFusion on September 17, 2006 at 7:00 pm by MrNate

One of my favorite bloggers, Sean Corfield, wrote that he wanted to see a way to invoke ColdFusion from the command line. A day or so later, Ashwin Mathew wrote how to do just that using cURL. It basically just hits your CFC path using the url invoking syntax (?method=myFunction&arg1=abc).

This doesn't really satisfy me.

It forces you to expose CFCs in your webroot, forces you to have them access=remote, and has the potential to force network access, especially if your site is using host headers or if you are accessing it via a public domain name.

It seems to me, a cleaner way to do this would be to invoke your cfc via an event gateway, and, because there is no command-line event gateway type (yet), I'm thinking a socket gateway may just be the way to go. Think about it, it's local, won't require network or dns access, connects directly and can send/receive feedback inline. Of course, telneting to it is cumbersome, so a simple jar or script that you could call seems logical. Depending on the implementation, you could even allow it access to any cfc or cfm on the system. Calling syntax would be something like:

java -jar CFCLISocket.jar com.mysite.myapp.myobject.mymethod(abc)

Simplify that through a shell script or batch file to make your life easier.

The Java behind it would make a socket connection to on a specified port and send the code you want to evaluate as a string to the event listener.

A slightly cleaner way to do this would have to be through a custom gateway specifically written for command-line invoking. It would execute the same, but the jar to invoke would be even easier to write (and potentially safer).

The best imaginable way would still have to be real actual support written into the CF server. I imagine this would be like php, where you can execute a php page straight from the CLI. Nice feature, steal it!

Of course, all of this is theoretical. Big help, I know, for those of you out there looking for an immediate solution.

Too old to comment!
On Sep 17, 2006 at 7:00 PM Tunaranch (haikal has underestimated the power of said:
A separate JRun instance, restricted to localhost (Most webservers can do this) would get rid of the security headaches associated with access=remote, wouldn't it?

On Sep 18, 2006 at 7:00 PM Ashwin ( said:
You could make checks in the your CFC to ensure that the caller is localhost via CGI.SERVERNAME, or even check that the caller belongs to a whitelist of IP addresses that are allowed to call the CFC via CGI.REMOTE_ADDR. Could these capabilities be built into a gateway? Sure... but putting them in a base CFC is a lot quicker!

On Sep 18, 2006 at 7:00 PM Toby Reiter ( or or said:
Ultimately, other than having this built-in to CF, Nathan's solution seems a much better choice. Why? Because why should my CFC have to know it's going to be accessed remotely just so I can run it from the command line?

Putting security checks in the CFC itself or having it extend the base component seems to be a Bad Idea (TM) because of the amount of coupling involved.

One idea that does occur to me:
Create a web service CFC that allows you to specify parameters (component location string, method, and an argument collection) and then call that using the curl tip mentioned by Ashwin. This could run in its own instance of JRun, filter based on client IP, or have any number of security protections added transparently (without having to modify the target CFC).

On Sep 19, 2006 at 7:00 PM Ashwin ( said:
Or, I would imagine you could use ColdSpring to weave the logic around your function invocations.
Too old to comment!