After some great conversations in the ColdBox forums, I got inspired and whipped up our next version of our GroovyLoader project, part of our projects pack that you can find in our extras download.  This version includes several updates like it sports a new interceptor called GroovyStarter that you can configure in your coldbox.xml and the entire groovy environment will wrap itself and become available in any coldbox app.  Not only that, but now you can also add any amount of java library locations and the plugin will java load them at startup into your application.  These libraries can be Spring, Hibernate, Apache Commons, etc.  And to top it off, we also added the ability to groovy load one or more paths to the loader.  Before you had to configure the groovy class path to one single location where groovy scripts/classes could be found.  Now you can do as many as you like and the loader will try to find it in any of those locations.  Pretty Snazzy!! Finally, what good is a project without documentation, so we now have the project fully documented: http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbGroovyLoader For those that do not know what you can do with ColdBox's GroovyLoader project, here is a simple list:

• script in groovy in any part of the coldbox lifecycle using <groovy:script> tags
• binding of variables between the groovy language and coldbox
• ability to load groovy scripts
• ability to load groovy classes with complex relationships
• ability to load java libraries alongside groovy classes
• no need to tweak the server or configure the server for operation
• much more...

Look how hard it is to add groovy language support to a ColdBox App: <!-- Groovy Starter: Creates & configures the GroovyLoader -->
<Interceptor class="${AppMapping}.plugins.GroovyLoader.GroovyStarter">
<!-- Paths that hold groovy libs -->
<Property name="groovyLibPaths">/${AppMapping}/model/groovy</Property>
<!-- Paths that hold jar's for us to load automagically -->
<Property name="javalibPaths">/${AppMapping}/model/lib</Property>
</Interceptor>

When using ColdBox's SES routing mechanisms you will come to a point where you would like to create variables depending on when a specific route matches or not.  You can do so very easily by using the argument called matchVariables, which is a simple string of name-value pairs you want to create in the request collection (This was added in version 2.6.3).  However, a hidden feature that we just documented that has been enabled since version 2.6.0, is that you can also pass named arguments to the addCourse() method and have them created on the request collection when the route matches.  This makes it much much easier to create simple or complex variables than a simple string of name-value pairs.

Example using matchVariables:

<cfset addRoute(pattern="space/:space",handler="page",action="show",matchVariables="spaceUsed=true,foundAt=#now()#")> That route will create the spaceUsed,foundAt variables in the request collection when the route matches. However, let's see how easy it is to do it using by convention name-value pairs in the method. <cfset addRoute(pattern="page/:page",handler="page",action="show",foundAt=now(),internalNamespace="_internal",hashMap=structnew())> I just added the foundAt,internalNamespace, and HashMap variables just by adding them as virtual arguments. It gets even better if you are running Railo because you can use implicit Array/Structure notation to create very complex variables. Again, this is now a documented feature in the wiki, so enjoy.

Dutch Rapley has contributed two nice additions, a POST method plugin and a form inspector interceptor. Please check them out here in our code depot.

Ernst has been busy and has updated his SSL Interceptor to do specific events and even pattern matching for events. So check his article out, truly nice work!!

Ernst has just posted his code for an ssl interceptor he just created. It looks awesome so take a look for yourself.