This blog is an archive. See our new blog at http://blog.mach-ii.com.

Some links may be outdated. Our Trac and SVN have moved:

Mach-II Runs on Google App Engine with Open BlueDragon

Those of you following the Open BlueDragon project know that there's some great work going on with OpenBD on Google App Engine. If you're not familiar with Google App Engine it's a really simple way to deploy applications written in either Python, Java, or now CFML, onto Google's cloud.

Dave Shuck recently contacted us and pointed out that due to some of the restrictions on Google App Engine, the "depends" attribute doesn't work. This is because up until now, the way "depends" worked was to inject methods into CFCs, write a modified version of the CFC to disk, and then instantiate the modified CFC from disk.

Since this was a no go on GAE, Peter looked into other ways of solving this problem. What he came up with is not only slick, but in the isolation test Peter created it garners a 9500% speed improvement (no, that's not a typo) over the old way of doing things. Note that "depends" only comes into play at load time, but shortening the load time in such a dramatic way means faster development for you. You can see details of the changes in ticket 456.

With the new "depends" functionality in place Mach-II 1.8 now runs great on Google App Engine with no changes to Mach-II itself, as you can see in Dave Shuck's test application on GAE.

Thanks to Dave for bringing this to our attention and for pushing the envelope with CFML on GAE. Having Mach-II running on GAE is fantastic, and the speed improvements it led to aren't bad either!

Announcements, Google App Engine, Mach-II 1.8  |  Send
Posted 11/21/09 @ 1:58 PM by Matt Woodward

Comments

How did he fix it!? I've been trying to figure out how to generate CFCs at runtime without writing to disk.

Posted by Russ S. at 11/21/09 8:18 PM

We're no longer generating any CFCs. It is impossible in pre-RAM based CFML engines to do this. The getters/setters that are injected follow an extremely predictable pattern. We are instantiating a generic bean with a whole bunch of "template" like setters/getters. They are named set1()/get1(), set2()/get2() and so on. Now it's impossible to change the internal structure of a method at runtime, but you can assign a method to a new name.

Take this example of injecting UserService into a listener. I'll assign setUserService() and getUserService() by injecting set1()/get2() at runtime into the target bean. Basically we are injecting this type of code at runtime (remember that getUserService is just get2() behind the scenes):

This is how we can inject generic getters and setters because we create a look up map for the how the setters / getters access data. It's a bit complicated, but all we are doing is exploiting method injection and access to the CFC variables scope. It is pretty limiting on what you can do, but in the case of how we are using it -- it's a perfect use case of getting around it. Anything more complicated and this solution would fail pretty fast.

Posted by Peter J. Farrell at 11/22/09 1:33 AM