I had some relative success doing that for Hibernate alone, in a classloader, so as to get the "on the fly" loveliness. I was doing a lot with the entity-based hibernate objects (hashmaps), to get a lot of dynamicalness out of it, too. Haven't decided which is better… hibernate is basically a whole framework-ish-deal, when you get really into it– but then your model is hibernate-based, which might kinda suck sometimes…

I was thinking the groovyLoader, being designed for crazy classloading, might not have such a rough time with garbage collection and whatnot. Eh.

Been experimenting here and there (mostly checking out GORM-without-Grails stuff lately, as it sounds nifty), but I haven't really messed with a spring-based java model… after all the stuff I've seen lately tho, spring is at least as cool as ColdSpring ;-), might not be a bad thing to look into…

If the server isn't running out of memory while you're doing all your groovy stuff, then it looks like garbage collection *is* better when using a groovy classloader…. are you sure the reason it's running out of memory after a while isn't the URLClassLoader you're using to put groovy itself into play?

I've been doing a lot of load testing lately, guess I can slap some experiments together to see what happens.

yep, that's exactly it. Unfortunately to get Hibernate to load new stuff, you have to tear it and it's classloader down each time, and one of the big goals of the Hibernate integration was to avoid having to restart your container every time. In development I've found I usually get 20-30 Hibernate reloads before I run out of PermGen and have to restart the container. Far from ideal, but way better than having to restart every time. And since it's not a factor in production (where you're not modifying files), I've deemed it "ok enough" to this point.

I haven't tried pre-compiled entities, but if you've got those, why not just use Spring (or a Configuration directly)? CFGroovy's stuff isn't going to buy you much, except for less flexibility. :) Behind the scenes, CFGroovy just compiles all your Groovy entities into .class files and loads them as if they were pre-compiled. The magic is in the ability to do it repeatedly without restarting the container.

I think the problem with Hibernate is that it uses the thread local context or whatever, and you're swapping the thread contexts around with the classloading, so the context that loads Hibernate isn't the same one using it (or something like that perhaps).

I'm pretty sure I've gotten hibernate to load in a classloader (had to be real careful that it didn't go "outside", like for dom4j (to read config.xml — I think I used properties instead)), so IIRC, it's doable, at least.

Had any luck using pre-compiled entities?

More specifically, importing the taglib and running it should be production worthy without any additional configuration. If you want custom classloading, Hibernate, etc., then you have to do config work, but for the base use (scriptlets) it should be 100% transparent.

Hmm… I just don't want my app to be broken when upgraded to CF9. Hope things will work out better later.

Yeah, that's the gist of it. You can use CFGroovy on CF9 without issue, but you can't use the HibernatePlugin on CF9 unless you delete the Hibernate JAR from the CF classpath, breaking the in-build CF9 Hibernate stuff. It seems unlikely that you'd want to use both CFGroovy's Hibernate and the in-built stuff on a single CF9 instance, so I'm not sure how much of a problem it'd be in real life, but certainly undesirable.

I hope I can deal with this issue in the future (since it affects JBoss 5 as well), but right now it's a couple items down the list. First priority is resurrecting seamless scriptlets, since that seems to be the bigger long-term win, as well as the original objective.

Yeah, entirely possible. I've never used JBoss for anything. The issue with classloading is that Hibernate and the entity classes have to be loaded in the SAME classloader. So if Hibernate is already loaded anywhere, CFGroovy can't hope to work, since the entity classes don't exist until CFGroovy gets it's hands on them.

And, other apps can include hibernate and work, so I think that the main problem is how the classloading/dynamic stuff is resolving things, or some such.

Changing to a child first classloading deal for the EAR I have railo in doesn't do anything different for cfgroovy, but cfgroovy isn't being deployed the way a WAR or EAR would be, so… eh.

'course, there's always the route of compiling the model sources first, and including them while loading hibernate; which probably wouldn't be too bad, as that's sorta what happens anyways… eh*2.

It might have taken me 8 years or so to figure out how to include commons-logging without messing up other applications, but I did it. This seems similar, but not as inherently broken, so hopefully in like 4 or so, perhaps 6 to be safe… :-)

Yeah, if you remove it from the server, it won't be available to any applications. But that shouldn't prevent you from adding it to the applications that needed. You just can't have the server providing it to ALL applications. That's really the way you want to be doing it anyway so that each app can depend on its own version of Hibernate and upgrade separately from everything else.