This is the final expected RC for CFGrovoy 1.0 and includes a couple more API tweaks (backwards compatible, of course). Bad form to do this right now, but like the attributes-to-params change, I want to get them in before the 1.0 release so I can build the next round of enhancements without mucking up the API. Hopefully. All the changes deal with Hibernate session management, so if you're not using HibernatePlugin, nothing has changed.
From most to least relevant, here are the changes:
- HibernatePlugin's getSessionForRequest and closeRequest methods are deprecated and replaced with getCurrentSession and closeSession
- I've added openSession to HibernatePlugin (which always creates a new session) to complement getCurrentSession (which creates on demand).
- The 'sessionFactoryWrapper' binding has been deprecated and replaced with a new 'sessionFactory' binding. It still points to the same object (an instance of SessionFactoryWrapper)
- SessionFactoryWrapper (the internal Groovy class) has had exactly equivalent changes made to it, with the three new methods NOT requiring a pageContext parameter. Instead, a setPageContext method is exposed for providing it once per request.
- HibernatePlugin has grown an initializeRequest method that will call SessionFactoryWrapper.setPageContext for you. Call from onRequestStart or the like.
Just to be clear, the API changes are backwards compatible; existing applications can continue to use the deprecated methods for the time being, but updating to the new API is recommended. After a couple weeks in the wild I'll tag an release an official 1.0, hopefully exactly matching RC3.
As always, engine source and the demo app (including the engine) are available from Subversion, and full details are on the project page. I've not bundled a ZIP download of this release since I figure most people will just wait for the official 1.0 release since no bugs were fixed.
Sweet Barney!
I've had a lot of fun with your cfgroovy stuff. Funny the way your hibernate deal is going, it's getting close to what I came up with for using hibernate from CF. The object translation (so to speak) was always kinda messy tho, every way I came at it.
Using Groovy is better than a java model, and negates a lot of problems with CF Java.
BTW, when deploying CFGroovy Hibernate Stuff on JBoss (which already has hibernate) things can get messy. A wonderful magical classloading type deal. "Wonderful magical" being sarcasm, of course. Haven't really found anything elegant to fix that, but I'll holler if I do.
Anyways, keep up the good work. Swell stuff!
Great stuff Barney! So can I now write all of my domain objects in Groovy and take advantage of hibernates power? How does the data source get configured for hibernate? Can I provide constraints right in my domain object? These are all questions I have but I should probably download the project again before I start asking away. Thanks!
@Denny
JBoss doesn't like it? CFGroovy loads Hibernate in it's own classloader, and it's a RootLoader so it should check itself before it goes up the ClassLaoder tree (the reverse of normal ClassLoader behaviour). Would it be possible to come up with instructions on how to replicate the issue(s)?
@Dan
Yeah, that's exactly it. You build your persistent entities in Groovy, configure Hibernate with the standard JPA and Hibernate annotations (or you can use XML if you really want), hand it a DSN and magic happens. Behind the scenes CFGroovy will create a DatabaseConnectionProvider backed by the DSN, wire up a Hibernate SessionFactory with it an your Groovy entities, and let it do it's thing.
Your domain objects can do anything that Hibernate lets them. That's the beauty of it, once you get to that level, CFGroovy is completely out of the picture, you're just using raw Hibernate and all it's capabilities.
@Barney I think it's because Hibernate looks at the context classloader, or some such. I've run into this before, it's almost similar to the problems you get with commons-logging (which I /finally/ overcame, thanks to SLF4j!).
This is with JBoss AS 5, which I don't think is final yet, but it's getting there (and I'm really loving it so far. Good cluster stuff, faster (a bit), etc.).
I think a test case is as easy as firing up a JBoss-ed CF instance, and trying the hibernate stuff. Everything else works fine.
BTW, have you thought about adding an createObject kind of call, as well as the runScript stuff? That's one of the hacks I've done, and it's been nice. I can send you my frankensteinian hack job of the older CFGroovy if you want to see what I mean.
@Dan For constraints, hibernate has a thing called "Hibernate Validator" which handles validation constraints (some of them) length, null/not null… adds resource bundles for error messages and whatnot. Not too bad. It's stand-alone tho (not built into hibernate).
I've enjoyed using GORM (part of Grails), which has some nice constraint stuff built right into the groovy domain objects. I think I like it's approach better than hibernate validation annotations, but I'm still on the fence — hibernate is like white rice.
There are some really cool tools like Drools, or jBPM (iirc) for doing hard-core validation… Drools doesn't look too painful (rule based workflow type stuph), and it has good rule/workflow editors…
Eh. Too much fun stuff! :-)
Again, woohoo for you, Barney! Nice implementation of Groovy in CF you got here. =]
Thanks!
@denny
Do you know if JBoss/Railo has the same issue?
I wasn't sure about how best to package a createObject-style UDF, since you have to include the UDF anywhere you want to use it, and that can be a mess. But you can do this:
<g:script script="variables.myObj = new MyNeatClass()" />
Not quite as simple, but it lets you call the class constructor in a Groovy context for the automatic map-based property setting
@Barney
Whoops, shoulda been specific– I haven't tried the cfgroovy stuff on Adobe CF on JBoss, I've only tried it on Railo CF on JBoss. I'm just so happy with Railo, I haven't really bothered to cross-test stuff much lately.
I'm pretty sure the same issue would pop up tho, as I was dicking with Hibernate and Adobe CF for a while, and I saw it there (I always run CF under JBoss, it's my container of choice) first.
Here's my createClass function: http://coldfusion.pastebin.com/m4e784b26
Nothing special, same general idea as what you suggested. It's just been nice to pass a cfgroovy object and use it to create groovy objects sorta like java ones.
I've got all of it bundled into a classloader now, so no need to add jars/restart (I verified the hibernate stuff wasn't working under jboss before I did that, as it can add complexity).
I'm pretty sure that the only way I've gotten hibernate to play with cfgroovy under jboss is to have the domain objects pre-compiled, and load them at the same time as loading hibernate, so hibernate doesn't get confused as to where the classes should be loaded from, or which hibernate to use.
Probably some simple flag to set or some such (maybe just setting the current context classloader, I've gotten close doing that, IIRC) to make it work, but that's what I've got so far, I think.
Ironic that Hibernate would be causing problems like commons-loggings did. Writing containers must be a total bitch.
Class loading for fun and profit! ;]
I am having a problem checking out the code from the sample-blog area. I get what looks like a basic-auth pop up for the coldspring external link in the lib directory. Submitting it with no username/pass doesn't work. Thanks!
@Dennis
Yeah, don't do that.
It's not really a sample app yet, just the start of one, and a playground for some of the new features coming in 1.1. I've removed the auth requirement for my vendor directory so the external should work, but you'll probably be disappointed by what you get. :)