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. :)

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! ;]

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

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!

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.

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)?

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!