Until this point, CFGroovy2 has used a custom WeakHashmap/WeakReference caching mechanism for compiled scripts. It works, and it ensures that the script cache won't run your JVM out of memory, but that's about it's only selling point.
Today I plugged in Ehcache as an optional caching backend if it's available on your classpath. When CFGroovy2 spins up it's internal infrastructure (on first use, and stored in the server scope), it will see if Ehcache is available. If it is, it will be used, otherwise the original mechanism will be. Note that JavaLoader is not used to load Ehcache; you must have Ehcache on your classpath if you wish to use it.
To complement this new behaviour, I've also added a <g:manager> tag. You can use it to clear the script cache, as well as retrieve information about the cache. To clear the cache, you can do this:
<g:manager action="clearCache" />
If you want to see how big the cache is, or view performance metrics (Ehcache-only), you can do this:
<g:manager action="getCacheInfo" Â result="info" />
The 'info' variable is guaranteed a 'usingEhcache' value (boolean or 'unknown'), along with a 'cacheSize' value (integer). With Ehcache, you'll also get hits, misses, and evictions (all integers).
As always, the runtime data structures are stored in server.cfgroovy should you wish to introspect them directly. However, they are not part of the public API, and are therefore not guaranteed to remain unchanged across releases.
Subversion access for the engine is here: https://ssl.barneyb.com/svn/barneyb/cfgroovy2/trunk/engine. If you already have Groovy on your classpath or are planning to put it there (which is recommended), you only need 'script.cfm' (and optionally 'manager.cfm').
[...] couple months ago I added Ehcache support to CFGroovy2 as an alternative to the simple HashMap/WeakReference caching that had been there since it's [...]