CFGroovy Updates

I made a bunch of updates to CFGroovy tonight, mostly centered around two main objectives:

  1. refocus on the original objective, inline Groovy scriptlets
  2. support Open BlueDragon

The first objective is based on my experience developing the last couple apps I've used CFGroovy on.  Hibernate is kickass, but neither of the apps used it; they only used CFGroovy for scriptlets.  What I discovered was that while using CFGroovy is pretty simple, it's not really all that friendly towards a pure-scriptlet use case.  Adding Hibernate provided a huge boost in capabilities, but it also roughed up the edges of the core Groovy engine quite a bit more than I had realized, and you pay the price regardless of whether you're leveraging Hibernate or not.  As powerful as Hibernate is, I still think scriptlets are the real win.  If you get scriptlets, Hibernate becomes just another Java API you can easily leverage from CFML.

So I've started going back through with a focus on smoothing those things back out.  The specific objective is to be able to download CFGroovy, drop the JAR into my /WEB-INF/lib folder, CFIMPORT the taglib, and run <g:script> in a production-ready fashion.  Obviously it can't hope to support a custom classpath, precompilation, Hibernate, etc., but that's not the point if you just want scriptlets.  There's no reason CFGroovy can't support both use models equally well.  Immediately following that objective is that taking an app and "upgrading" to a more customized CFGroovy configuration should be transparent to the code.  Just new configuration in Application.cfc or ColdSpring and the app automatically adjusts.

And yes, CFGroovy no longer bootstraps itself into it's own little world, including loading it's own Groovy JAR.  Compared to spinning up Hibernate the cost of doing that is a drop in the bucket, but it's not acceptable for my above-stated goal for various reasons.  So I've reverted to requiring installation of the JAR.  Certainly an added hardship, but to get production-ready performance and memory consumption out of the box, it has to be that way.  It also makes the internals enormously simpler.

The other major change is that CFGroovy is no longer implemented in Groovy, it's 100% CFML again.  This is for much of the same reason as the JAR loading: the price is too high in terms of performance and memory consumption for the pure-scriptlet class of development.  I'd rather implement in Groovy than CFML because everything is Java APIs, but bootstrapping a Groovy environment to bootstrap the CFGroovy environment effectively doubles the initialization work.  Only measured in tenths of seconds at the most, and therefore invisible if you're spinning up Hibernate, but a non-trivial penalty if you aren't.

Second, Open BlueDragon support is mostly there.  The pre-1.0 releases had some classloading issues that prevented stuff from working, so I just wrote it of.  However, I decied to give it another try tonight on a whim, and those issues seem to be resolved.  The core CFML->Groovy->CFML flow works perfectly, but there are a number of warts.  OBD doesn't support recursive CFDIRECTORY so a number of things simply fail, including packaged classes.  It also doesn't handle all the Java numerics so if you do floating-point math in Groovy you may or may not get back a number you can use in CFML.

That said, if you checkout trunk from Subversion onto a OBD instance, you'll be able to run all the Groovy demos except "Simple Objects" (because of the numerics issue – java.math.BigDecimal specifically).  The Hibernate integration currently depends on packaged classes which OBD can't compile, but if I can get access to the datasource information as I can on CF and Railo, I think Hibernate will work as well.

Finally, I want to give a big shout out to my version control system.  The ability to go back and selectively revert individual changes in individual files from the past four months saved me hours and hours of headaches.  If you don't have version control set up for every line of code you write, stop reading right now and go do that.  Then you can come back and finish.

As always, source is available at  That's the demo app, as you'd imagine from the URL, which includes the actual CFGroovy engine.

7 responses to “CFGroovy Updates”

  1. Pat Santora

    Great stuff as always Barney!

    Check out this post in regards to integration issues with jboss. We've talked about this offline, but would love to get this working in such an environment.

    Think you can give a hand with getting this going? I can be available if necessary to assist.


  2. Pat Santora

    Right now I am in using JbossAS5 which has hibernate pretty well integrated and unfortunately we I need something rather quick lol.

    Now when you say remove hibernate3.jar from my classpath are you referring to removing it from jboss or from cfgroovy? I'm going to assume the first. If that's the case it's not really that easy as once I remove the file Jboss just pisses all over itself complaining multiple times (once per deployment attempt from the tomcat integration).

    Sounds like I will need to stab at this myself to make progress. I am very eager to see hibernate in Centaur btw. That will be oh so sweet… hopefully!

    Thanks for the quick post and I did not read it as a "piss off" :). At least you posted saying you did not have time rather than having the other person just wait with nothing. :)


  3. Henry Ho

    Can we update Groovy independent of CFGroovy?

    What version of Groovy is CFGroovy using right now?

    Are you planning to setup a user group, maybe on Google Group, for the CFGroovy project?

    Thank you!

  4. Henry Ho

    oh? so groovy-all-1.6.0.jar has no CFGroovy specific code?