I made a bunch of updates to CFGroovy tonight, mostly centered around two main objectives:
- refocus on the original objective, inline Groovy scriptlets
- 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 https://ssl.barneyb.com/svn/barneyb/cfgroovy/trunk/demo. That's the demo app, as you'd imagine from the URL, which includes the actual CFGroovy engine.
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.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225775#4225775
Think you can give a hand with getting this going? I can be available if necessary to assist.
Cheers,
-Pat
Isolation was the primary goal of the internal restructuring I did, but it didn't pan out for beans, which is why I undid it. If Hibernate loaded by the app server can load classes deployed in a webapp, then the same sort of thing should be doable across CFGroovy, barring it relying on some magic implemented within JBoss itself. I.e. if it's a Hibernate feature, I should be able to leverage it.
If you want to hack around a bit, have at it. Check out the source, and if you make things happier, shoot me a patch. Do it often enough (like twice ;)) I'll just set up commit access, because I'm lazy. JBoss is not something I use, and while it's a major player in the CFML server market (and growing), I don't have the resources to spend much time on random feature X at the moment. CFGroovy dev is still need driven, at least to a certain extent. Such is life in the world of small open-source projects. ;)
Don't take that as a "piss off", just "I'm not going to jump on it." At the moment my official position on JBoss (and Centaur) is "remove hibernate3.jar from your classpath", and it'll probably be that way for at least a little while. The release of Centaur will accelerate that need significantly, if you can wait that long.
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. :)
Cheers,
-Pat
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!
Henry,
Yeah, you bet. The version of Groovy that comes with CFGroovy is what I've done my testing with, but pretty much any recent version should work. I included 1.5.6 for a while, and upgraded to 1.6.0 with no changes to my code, and that's where it's at today. That said, it uses whatever Groovy happens to be installed into your web application, you can pick whatever you want.
I haven't really considered setting up a Google group (or whatever) since I'm not sure how much utility it would have, and I don't really want to have to moderate something. However, if someone wanted to set something up (nudge nudge), I'd be more than happy to "bless" it and point people at it.
oh? so groovy-all-1.6.0.jar has no CFGroovy specific code?
Thanks
Henry,
Correct, the JAR distributed with CFGroovy is a vanilla distro from the Groovy language project itself. I only include it in there so that people don't have to go find it themselves.
The APIs that CFGroovy uses internally are quite simple, mostly enforced by the scripting spec (JSR 223), and are global all scripts. To put that another way, pretty much any future Groovy version should work flawlessly, but if there is a problem it should be obvious and immediate, not some subtle latent bug that only rears it's head in certain circumstances. I'm only talking about the CFGroovy code itself, of course, your Groovy scripts might have all kinds of issues. I know mine often do. ;)